The COSO Internal Control—Integrated Framework was developed by the Committee of Sponsoring Organizations of the Treadway Commission. That led to the term COSO. The organization was formed in 1992 with the main idea of creating a framework of controls to ensure a company’s financial reports were accurate and free from fraud. The COSO framework has evolved over the years with the latest version published in May 2013. Since 1992, both technology in general and the Internet in particular have evolved. Not surprisingly, technology and information security have become major parts of the COSO controls framework.

In fact, COSO, like Control Objectives for Information and related Technology (COBIT), is often used by auditors, compliance professionals, and risk professionals. COSO is widely used and recognized as a major U.S. standard that has been adopted worldwide. Because COSO controls apply both to business functions (such as financial accounting) and to technology (such as information security), they make a powerful framework. The framework can describe how controls should be built, in both business and technology terms. This has enormous benefits for the security team. The security team can build controls in a way that the business side is more likely to understand. That makes it a little easier to talk the language of the business side. That, in turn, leads to greater business support for adopting the security controls.

The COSO control framework works well with other frameworks, such as COBIT. In fact, COBIT 5 leverages both COSO and International Organization of Standardization (ISO) principles and extends the work into many information security areas not handled by COSO. So rather than competing, these frameworks actually complement each other.

COSO outlines how controls should be built and managed in order to ensure compliance with many major regulations today. For example, the governance body for the Sarbanes-Oxley (SOX) Act of 2002 recommends the COSO internal framework as a means of compliance with SOX. In other words, if you implement the COSO control framework, you will be compliant with SOX regulations.

Consequently, COSO is a powerful framework to ensure that risks are well managed and the right controls are built to keep systems compliant with many laws and regulations.

The Security Content Automation Protocol (SCAP), pronounced “S-cap,” is a technology used to measure systems and networks. It’s actually a suite of six specifications. Together these specifications standardize how security software products identify and report security issues. SCAP is a trademark of NIST.

NIST created SCAP as part of its responsibilities under the Federal Information Security Management ACT (FISMA). The goal is to establish standards, guidelines, and minimum requirements for tools used to scan systems. Although SCAP is designed for the creation of tools to be used by the U.S. government, private entities can use the same tools.

The six specifications are:

• eXtensible Configuration Checklist Description Format (XCCDF)—This is a language used for writing security checklists and benchmarks. It can also report results of any checklist evaluations.
• Open Vulnerability and Assessment Language (OVAL)—This is a language used to represent system configuration information. It can assess the state of systems and report the assessment results.
• Common Platform Enumeration (CPE)—This provides specific names for hardware, operating systems, and applications. CPE provides a standard system-naming convention for consistent use among different products.
• Common Configuration Enumeration (CCE)—This provides specific names for security software configurations. CCE is a dictionary of names for these settings. It provides a standard naming convention used by different SCAP products.
• Common Vulnerabilities and Exposures (CVE)—This provides specific names for security-related software flaws. CVE is a dictionary of publicly known software flaws. The MITRE Corporation manages the CVE.
• Common Vulnerability Score Systems (CVSS)—This provides an open specification to measure the relative severity of software flaw vulnerabilities. It provides formulas using standard measurements. The resulting score is from zero to 10, with 10 being the most severe. There is a formula that includes several separate criteria that all influence the final score.

SCAP isn’t a tool itself. Instead, it’s the protocol used to build the tools. Compare this to Hypertext Transfer Protocol (HTTP), the protocol that transmits traffic over the Internet so that applications can display data in user applications. Web browsers can display pages written in Hypertext Markup Language (HTML) and Extensible Markup Language (XML). However, HTTP can’t display the traffic itself. Instead, web browsers such as Edge, Firefox, or Chrome are the tools that use HTTP to transmit and receive HTTP traffic and display the HTML-formatted pages. Similarly, SCAP-compliant tools use the underlying specifications of SCAP to scan systems and report the results. There are a wide variety of tool purposes. These include the ability to audit and assess systems for compliance with specific requirements. They can scan systems for vulnerabilities. They also can detect systems that don’t have proper patches or are misconfigured.

Some of the tools currently available are:

• BigFix Security Configuration and Vulnerability Management Suite (SCVM)
• Retina by eEye Digital Security
• HP SCAP Scanner
• SAINT vulnerability scanner
• Symantec Control Compliance Suite—Federal Toolkit
• Tripwire Enterprise

If you want to read more about SCAP, read NIST SP 800-126. This is the technical specification for SCAP version 1.3. At this writing, NIST SP 800-126 rev 3 is in draft. It is the technical specification for SCAP version 1.1. You can access NIST SP 800-126 and other NIST 800-series special publications at http://csrc.nist.gov/publications/PubsSPs.html.

The Simple Network Management Protocol (SNMP) is used to manage and query network devices. SNMP commonly manages routers, switches, and other intelligent devices on the network with IP addresses. SNMP is a part of the TCP/IP suite of protocols, so it’s a bit of a stretch to call it an emerging technology. However, SNMP has improved over the years. The first version of SNMP was SNMP v1. It had a significant vulnerability: Devices used community strings for authentication. The default community string was “Public,” and SNMP sent it over the network in clear text. Attackers using a sniffer such as Wireshark could capture the community string even if it was changed from the default. They could then use it to reconfigure devices.

SNMP was improved with versions 2 and 3. Version 3 provides three primary improvements:

• Confidentiality—Packets are encrypted. Attackers can still capture the packets with a sniffer; however, they are in a ciphered form, which prevents attackers from reading them.
• Integrity—A message authentication code (MAC) (not to be confused with Media Access Control) is used to ensure that data has not been modified. The MAC uses an abbreviated hash. The hash is calculated at the source and included in the packet. The hash is recalculated at the destination. As long as the data has not changed, the hash will always provide the same result. If the hash is the same, the message has not lost integrity.
• Authentication—This provides verification that the SNMP messages are from a known source. It prevents attackers from reconfiguring the devices without being able to prove who they are.

Web-Based Enterprise Management (WBEM) is a set of management and Internet standard technologies. It standardizes the language used to exchange data among different platforms for management of systems and applications. Just as SCAP provides the standards used to create tools, WBEM also provides standards used in different management tools. The tools can be graphical user interface (GUI)–based tools; some tools are command line tools that don’t use a GUI.

WBEM is based on different standards from the Internet and from the Distributed Management Task Force (DMTF), Inc. DMTF is a not-for-profit association. Members promote enterprise and systems management and interoperability. These standards include:

• CIM-XML—The Common Information Model (CIM) over XML protocol. This protocol allows XML-formatted data to be transmitted over HTTP. CIM defines IT resources as related objects in a rich object-oriented model. Just about any hardware or software element can be referenced with the CIM. Applications use the CIM to query and configure systems.
• WS-Management—The Web Services for Management protocol. This protocol provides a common way for systems to exchange information. Web services are commonly used for a wide assortment of purposes on the Internet. For example, web services are used to retrieve weather data or shipping data on the Internet. Clients send web service queries and receive web service responses. The WS-Management protocol specifies how these queries and responses retrieve data from devices. It can also be used to send commands to devices.
• CIM Query Language (CQL)—This language is based on the Structured Query Language (SQL) used for databases, and the W3C XML Query language. The CQL defines the specific syntax rules used to query systems with CIM-XML and WS-Management.

A digital signature is a value that identifies a file’s origin. Usually the data in the file is first hashed using a cryptographic hash, then signed (i.e., encrypted with the sender’s private key). Digital signing technologies provide added security for files. A file signed with a digital signature provides authentication and integrity assurances. It also provides nonrepudiation; in other words, it provides assurances that a specific sender sent the file. It also provides assurances that the file has not been modified.

A public key infrastructure (PKI) is needed to support digital signatures. A PKI includes certificate authorities (CAs) that issue certificates. The certificate includes a public key matched to a private key. Anything encrypted with the private key can be decrypted with the public key. Additionally, anything encrypted with the public key can be decrypted with the private key.

Digital signatures provide added security for many different types of policy compliance files. For example, consider patches and other update files. You would download these files and use them to patch vulnerabilities. If an attacker somehow modified the patch, instead of plugging a vulnerability, you would be installing malware. Similarly, many definition updates for security tools are digitally signed.

If a file is digitally signed, you know it has not been modified. The following steps show one way that a digital signature is used for a company named Acme Security. The company first obtains a certificate from a CA with the following steps:

1. Acme Security creates a public and private key pair.
2. Acme Security includes the public key that is part of its certificate request to the CA with the company’s request. It keeps the private key private and protected.
3. The CA verifies Acme Security is a valid company and is who it says it is. The CA then creates a digital certificate for Acme Security. The certificate includes the public key provided by Acme Security.
       At this point, the company is able to digitally sign files. Consider Figure 15-4 as you follow the steps for creating and using a digital signature.
4. Acme Security creates the file.
5. Acme Security hashes the file. The hash is a number normally expressed in hexadecimal. There are many hashing algorithms, but SHA-2 is one of the most widely used.
6. Acme Security encrypts the hash with its private key. The result is a string that appears to be random gibberish. Remember, something encrypted with a private key can only be decrypted with the matching public key. Said another way, if you can decrypt data with a public key, you know it was encrypted with the matching private key.
7. Acme Security packages the file and the digital signature together and sends them to the receiving client. The digital certificate could be sent at the same time or separately.
8. The receiving client uses the certificate to verify that Acme Security sent the file. Additionally, the client checks with the CA to verify the certificate is valid and hasn’t been revoked.
9. The client decrypts the signature with the public key from the certificate. That gives them the hash. They then generate their own hash of the file and compare it to the hash they received. Both should match perfectly.

Digital signatures aren’t a new technology; however, their use with security tools and downloads has significantly increased over the years. A digital signature provides you with an additional tool to verify authentication and integrity for downloaded files. It is likely that drivers you use for devices like printers are digitally signed.