by Phil Martin
We have mentioned both design and code reviews as if they are examined at the same time. While this may happen naturally, a separate formal design review should be held at the end of the design phase, and a formal code review should occur when development has wrapped up. Design reviews are meant to detect architectural flaws that would require a redesign before coding can commence. Recall that by definition a flaw is an architecture issue while a bug is a coding issue. Therefore, the design review is intended to uncover flaws, while a code review is designed to uncover potential bugs. Code reviews involve a line-by-line walkthrough of code along with an inspection of the overall functionality. This process is normally carried out with ‘peers’ of the development team and is therefore often called a peer review.
Automated source code scanning tools can be useful in finding inefficiencies and potential security problems, but their use must be taken in the proper context. Nothing can take the place of a human brain scanning source code, and a lot of false positives and false negatives will usually result from such a tool. A mature security effort uses both automated and manual processes to review code.
Testing
The second step in V&V after reviews, is to perform proper testing. This activity determines if software truly meets requirements and to note any delta between what is expected and the actual results. There are three types of V&V testing – error detection, acceptance, and independent.
An error detection test includes both unit and integration testing, which we have already discussed in-depth. An error may be a result of either a design flaw or a code bug. Beyond validating that software satisfies requirements, we can perform verification tests to assure the following:
Input validation is properly handled by using fuzzing techniques.
Output is properly filtered.
Error handling mechanisms are in-place.
State transitions are properly managed and secured.
Increasing amounts of load is properly managed and has been tested.
Interfaces to external consumers are resilient.
Temporal issues such as race conditions are managed properly.
Spatial issues such as locality of reference are managed, and memory usage is checked.
The software recovers to a secure state on failure.
An acceptance test demonstrates that software is ready for its intended use. This includes not only functional testing but security testing as well. When software is released in an incremental manner, regression testing must be part of acceptance testing to ensure that existing functionality and security has not been broken by the new release. Simulation testing must also be carried out in an environment that mirrors the production environment as closely as possible. This prevents problems post-deployment due to configuration and environmental differences. Once accepted, any changes to the software must go through a formal change management process.
Most often internal teams are used to test software, which has both pros and cons. The advantage of using internal teams is that they intimately know the software and can quickly identify root causes. The disadvantage to using internal teams is that they intimately know the software - and therefore lack objectivity. The same sharp sword can be used to cut our enemy as well as ourselves if we are not careful.
This is where independent testing can come in handy, in which a third party comes in to review, verify and validate software. Often called independent verification and validation, or IV&V, this approach can often help as the external party can afford to be completely objective as they have no vested interest in whether the software is successful or not – they simply report the raw results and let the business handle the fallout. As with any other external party agreement, IV&V requires a contractual arrangement with the rules of engagement clearly spelled out.
IV&V is especially helpful when it comes to validating vendor claims because we can transfer some of the liability of using external products to the third party that conducts the reviews and tests. However, if using IV&V, you are still responsible for being aware of the various tools and checklists used when the V&V process is being carried out.
Certification and Accreditation (C&A)
The natural outcome of a mature software acceptance process is the certification of the product to meet specific requirements. ISO/IEC 27006 can help with the certification process of an information security management system, or ISMS. While most software is not directly related to an ISMS, the standard is nevertheless useful when certifying and accrediting most other software.
Certification is the technical verification that software has met the required functional levels. This activity looks at the software as it functions in the intended environment, and takes into account everything including deployment, the production environment and security aspects. Security certification at a minimum should ensure the following:
User rights, privileges and profile management capabilities have been implemented properly.
Sensitive data and applications are protected by the appropriate controls.
System, facility and location configuration is properly managed and implemented.
Dependencies and interconnectivity with other environments and systems are properly protected.
The system operates in a secure mode.
While certification assures that a system meets certain requirements, accreditation is management’s formal acceptance of the system after understanding the inherent risks. When a system is accredited, management has accepted
the system to operate in the stated security mode for a predetermined amount of time. Software must be both certified and accredited before it can be accepted.
Chapter 43: The Security Role
The Security role must be taken on by someone, but the identity of that individual or department will depend on how mature an organization is in regard to security management. Some companies will have a chief information security officer, or CISO, or perhaps even a chief security officer, or CSO, that will head up security. On the opposite end of the spectrum, this role may fall to an architect or manager. To effectively produce secure software, though, at a minimum at least one individual must be assigned their full-time role of watching over security, usually as a Director of Security. This person must have the authority to require that secure standards are adopted as policy and are implemented in the daily life of the company. Otherwise, a truly secure software stance will never be achieved.
Security Standards
It’s great to have a security policy, but unless it is backed up by standards that carry out the policy, not a whole lot of good will come from it. There are two types of standards you will routinely encounter – internal and external, shown in Figure 134.
Internal standards are usually very specific, such as security coding standards which dictate the patterns and constraints that developers must follow when writing code. External standards can be further divided into four different groups – industry, government, national and international. A good example of an industry standard is the Payment Card Industry Data Security Standard, or PCI DSS. The National Institute of Standards and Technology, or NIST, produces many government standards.
Not all standards are enforceable or are recognized beyond the border of the United States, and this is the major factor in determining a national and an international standard. The best examples of an international standard are those created by the International Organization for Standardization, or ISO. National standards for the U.S. include those created by the Federal Information Processing Standards, or FIPS and by the American National Standards Institute, or ANSI. As the world continues to embrace a global mindset, most organizations will lean to adopting international standards over national ones.
Remember that while standards are mandatory, guidelines are not. External standards usually provide guidelines for organizations to adopt, but organizations quite often turn those external guidelines into internal standards, making them mandatory.
In the next
few sections, we are going to cover the most important standards, but it will be far from a complete list.
Figure 134: Security Standard Categories
Internal Coding Standards
An internal coding standard should be followed by all developers when writing code. These are not necessarily specific to a language, although it is not uncommon to see language-specific examples within the standard. A consistency in style can be achieved by requiring all developers to follow the same naming conventions and syntax, which in turn improves readability and maintainability. These attributes are important in environments with a high degree of employee turnover. For example, when a key developer leaves the organization, his or her replacement will have a much easier time of getting up to speed if coding standards have been enforced.
Coding standards can also increase security, and code that follows a good standard is less prone to error and exposure to threats. As an example, if the coding standard requires that all exceptions must be handled without revealing details to the end-user, then information disclosure is respected. If the coding standard requires that all try/catch blocks include a finally block where objects are disposed of, dangling pointers and the number of objects in memory are reduced, not only addressing security concerns but increasing performance as well.
PCI DSS
PCI DSS, commonly called PCI for short, is a rare bright spot in the security industry where private businesses decided to govern themselves and create a standard that was not required by a federal body. Had the PCI standard not been developed, you can believe the government would have stepped in at some point in order to secure payment account data. It was developed through a cooperative coalition consisting of American Express, Discover Financial Services, JCB International, Mastercard Worldwide and Visa, Inc. International. Not only does PCI include technology requirements, but it also covers security management, policies and procedures.
The stated goal for PCI DSS is to proactively protect card holder payment account data. To do this, there are 12 foundational requirements, grouped into 6 objectives, that any company processing credit card payments must align with.
Build and Maintain a Secure Network
Requirement 1: Install and maintain a firewall configuration to protect cardholder data
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
Protect Cardholder Data
Requirement 3: Protect stored cardholder data
Requirement 4: Encrypt transmission of cardholder data across open, public networks
Maintain a Vulnerability Management Program
Requirement 5: Use and regularly update anti-virus software
Requirement 6: Develop and maintain secure systems and applications
Implement Strong Access Control Measures
Requirement 7: Restrict access to cardholder data by business need-to-know
Requirement 8: Assign a unique ID to each person with computer access
Requirement 9: Restrict physical access to cardholder data
Regularly Monitor and Test Networks
Requirement 10: Track and monitor all access to network resources and cardholder data
Requirement 11: Regularly test security systems and processes
Maintain an Information Security Policy
Requirement 12: Maintain a policy that addresses information security
Some companies use third-party services such as PayPal to process payments. In these cases PCI compliance is not required. However, if a company transmits, processes or stores the primary account number, or PAN, then PCI compliance is necessary. Some data required to be collected is not allowed to be persisted in any form – even if encrypted - such as the full magnetic strip, the security code or the PIN. As this is a book about software security, let’s drill down a little further into ‘Requirement 6: Develop and maintain secure systems and applications’.
6.1 Ensure that all system components and software have the latest vendor-supplied security patches installed. Deploy critical patches within a month of release.
6.2 Establish a process to identify newly discovered security vulnerabilities, such as by subscribing to alert services, or using a vulnerability scanning service or software. Update the process to address new vulnerability issues.
6.3 Develop software applications in accordance with PCI DSS based on industry best practices and incorporate information security throughout the software development life cycle.
6.4 Follow change control procedures for all changes to system components.
6.5 Develop all Web applications based on secure coding guidelines and review custom application code to identify coding vulnerabilities.
6.6 Ensure that all public Web-facing applications are protected against known attacks with at least annual reviews of code, and by installing a Web application firewall in front of public-facing Web applications.
Data Element
Storage Permitted
Protection Required
Primary Account Number (PAN)
Yes
Yes
Cardholder Name
Yes
No1
Service Code
Yes
No1
Expiration Date
Yes
No1
Full Magnetic Stripe Data
No
N/A
CAV2/VC2/CVV2/CID
No
N/A
PIN/PIN Block
No
N/A
Figure 135: PCI DSS Requirements
If the PAN is being stored, these items must be protected as well.
Payment account data is very well-defined, as shown in Figure 135, and includes data elements such as the account number, expiration data and the security code commonly found on the back of a credit card. Each data element has its own requirements dictating if it can be persisted, and if so, if it must be encrypted.
Payment Application Data Security Standard (PA-DSS)
While the PCI DSS is a standard that an application must comply with in order to handle credit card data, how does PCI know if an application is compliant? Enter the Qualified Security Assessor, or QSA, which is a term applied to companies authorized by PCI to assess applications and determine if they are PCI DSS compliant.
The missing piece of this puzzle is how QSAs know if an application is PCI DSS compliant, and that is where the PA-DSS comes in. This standard acts as a template that a QSA can use when creating the validation report. One of the ‘gotchas’ with PCI compliance is that a system that does not handle payment data might need to be PCI compliant anyway if it connects to a system that does handle payment data. It all depends on what that ‘connection’ looks like. Furthermore, just because an application is PA-DSS compliant does not necessarily make it PCI DSS compliant, since the application must be deployed into a PCI DSS compliant environment.
Organization for the Advancement of Structured Information Standards (OASIS)
The OASIS consortium drives the adoption of open standards for the global information community. Some of the standards this organization have championed are the following:
Application Vulnerability Description Language (AVDL)
Security Assertion Markup Language (SAML)
eXtensible Access Control Markup Language (XACML)
Key Management Interoperability Protocol (KMIP) Specification
Universal Description, Discovery and Integration (UDDI)
Web Services (WS-*) Security
NIST Standards
The National Institute of Standards and Technology, or NIST, was created in 1901 by the United States congress to encourage standardization. This organization aids U.S. companies in the global marketplace by developing technologies, measurement methods and standards. Even though it is specific to the United States, due to outsourcing across the world NIST applies to many international agreements.
One of the core goals for NIST is to set
the security standards and guidelines for sensitive federal systems, but it is quite common for the private sector to voluntarily adopt these federal standards. The organization has created a series of Special Publications, most notably the SP 500 and SP 800 series. While SP 500 is targeted to more generic information technology topics, SP 800 is geared specifically for information technology security subjects. NIST also is responsible for creating the Federal Information Processing Standard, or FIPS. In this section we will cover both SP 800 and FIPS publications that are especially applicable to information security.
SP 800
NIST’s SP 800 series of publications are specific to the computer security community. While they have been developed to address the security and privacy needs of U.S. federal agencies and information systems, they are so helpful that the private sector normally adopts them as well.
SP 800-12: An Introduction to Computer Security: The NIST Handbook
This handbook provides an overview of computer security by providing guidance on securing hardware, software and information resources. Security controls are grouped into three categories – management, operational and technology. SP 800-12 focuses on the scenarios in which security controls would be of benefit but does not go into depth on requirements.
