Green Pace

[Virtual Presenter] Hi. My name is Vincent Bostic, and this is Project Two, Green Pace Security Policy Presentation. The purpose of the Green Pace Security Policy is to define core security principles and coding standards that align to accepted industry best practices. This policy applies to all staff that create, deploy, or support software developed at Green Pace..

[Audio] Defense in Depth is a well known strategy for taking a stance against intrusion, attack, and exploitation. The basic principle, is the use of multiple layers of independent, sometimes redundant protection measures. If one of these protections fail, the remaining measures will limit further intrusion or damage. Physical controls are put in place to prevent unauthorized access to physical system hardware. Technical controls are in place to limit unauthorized access across the network. From both internal, and external actors. Technical controls include access management systems, firewalls, encryption, and others. Administrative controls are policies and procedures to ensure quality software development, regulatory compliance, and provide guidance to management and personnel..

[Audio] The SEI-CERT Coding standards classify vulnerabilities in three categories. Level One, Level Two, and Level Three. These are based on the severity, the likelihood of occurrence, and the cost of remediation of the associated vulnerability, as shown in this chart. Risk mitigation efforts should be prioritized based on the categories as shown here. Defects that are unlikely to occur and have a negligible risk, are not considered a security issue. The threat levels associated with the 10 standards in this document, are discussed in the upcoming slides..

[Audio] The Green Pace Security Policy is based on the ten principles of secure coding you see here. With few exceptions, all ten principles must be kept in mind throughout the development lifecycle. Number one. Validate Input Data. Prevent injection, buffer overrun, or other memory related attacks by ensuring input data is the correct type and size. Number two. Heed Compiler Warnings. Compile code with the highest compiler warning option to reduce potential defects. Number three. Architect and Design for Security Policies. Build security into the system, not as an afterthought. Number four. Keep it Simple. Overly complex code that is hard to understand increases the chances of unrecognized defects. Number five, Deny by default. Provide access only to those people or services required to perform the necessary actions. Number six, adhere to the Principle of Least Privilege. Provide the minimum access level needed to complete a given task and only for the duration needed. Number seven, sanitize Data Sent to Other Systems. Only provide the data needed by the other system and in the correct form to prevent SQL or other injection attacks. Number eight, practice Defense in Depth. Multiple independent security measures for each physical, technical, and personnel interaction will reduce the chances of a successful attack and limit the damage if one does occur. Number nine, use Effective Quality Assurance Techniques. A robust quality assurance plan will reduce defects, remediation costs, and improve lifecycle performance. Number ten, adopt a Secure Coding Standard. A secure coding standard provides guidance to reduce exploitable defects..

[Audio] Prioritization of coding standards in this policy document follow recommendations of the SEI CERT, C and C++ Coding Standards. The first five standards concern high-risk vulnerabilities and are the highest priority. If ignored, risk opening a potential avenue where an attacker could inject and run arbitrary code. Standards six and seven also concern high-risk vulnerabilities which, if ignored, could lead to unintentional information disclosure or data integrity violations. Standards eight thru ten concern medium-risk vulnerabilities that could result in abnormal application termination, denial of service, and similar interruptions..

[Audio] Encryption policies are in place to prevent unauthorized disclosure of protected information. These are, Encryption at Rest, Encryption at Flight, and Encryption in Use. Encryption at rest helps protect data that is saved or archived on the network from unauthorized access. A single encryption key is used to both encrypt the data for storage and decrypt the data when needed. Encryption keys are stored in a secure location with access controls and audit policies. Encryption in flight helps protect data that is transferred over a network and is particularly critical for data transmitted over the internet. Data is encrypted before transmission and decrypted by the receiver. Encryption in use helps protect data when it accessed by a user or application. Typically, data in use is stored unencrypted in memory for the duration of its usage. This includes any form of data including encryption keys and certificates. In use encryption provides full memory encryption for the entire lifecycle of the data. The Green Pace encryption policy applies to any type of data requiring protection from disclosure..

[Audio] Triple-A Policies; Authentication, Authorization, and Accounting, ensure that users are identifiable, have proper authorization, and are accountable for their actions. Authentication is the process of identifying a user and ensuring they are who they claim. Each user's identification must be unique. Identification can be established through passwords, single sign-on systems, certificates, or biometrics. Authorization is the enforcement of policies that determine what resources a user may have access to. Users are assigned authorization levels, or group associations, that determine specific privileges the user has. Authorization provides a means of limiting access to only those resources which are needed by the user. Accounting tracks the resources an individual uses during a session and records the duration, data sent and received, and actions performed. Accounting ensures that an audit will enable administrators to determine what actions were performed, by whom, and at what time..

[Audio] The coding standard under test here, is STD-Ten-CPP. Use valid references, pointers, and iterators to reference elements of a container. Code using the standard library vector function can invalidate iterators, references, and pointers under certain conditions. The first three tests are positive tests confirming expected operation. The last three are negative tests that confirm what happens when invalid iterators or pointers are encountered..

[Audio] The first test simply confirms that resizing and empty collection does, in fact, increase its size when the new size is greater..

[Audio] The second test confirms that resizing a collection decreases the collection size when the new size is less than the former..

[Audio] The third test confirms that when resizing a collection with a value of zero, the new size of the collection is, in fact, zero..

[Audio] The fourth test confirms that a call to insert, will invalidate an iterator after the insertion point, causing the program to abort. Here we use EXPECT_DEATH to confirm this is true. The first function call, Crt Set Report Mode, restarts the program to continue with the remaining tests without interruption..

[Audio] Like the insert function, erase also invalidates an iterator at the point, or after the point of erasure, causing the program to abort..

[Audio] When a container is cleared, all elements of the container are destroyed and all pointers and references to the collection are invalidated..

[Audio] Here are the results of the complete test execution with all tests passing as expected. As noted previously, insert and erase result in an invalid iterator which results in a program abort so the function CrtSetReportMode is used to continue testing uninterrupted..

[Audio] The DevSecOps pipeline begins at requirements analysis and continues through production. Testing for compliance to coding standards in this document begins with the selection of tools needed to enforce the development of software free of the associated vulnerabilities. Planning will include consideration of application deployment environment and assessment of associated risks and potential attack vectors. Legal and regulatory requirements will be revised with each iteration. Unit tests and compliance tests are developed with each component during build. Vulnerability scans, functional tests, and security auditing, will be conducted before release to production..

[Audio] The DevSecOps Pipeline is a continuous process of development, testing, and monitoring beginning with planning and continuing through deployment. Automation tools are essential throughout the process. Automation begins in the build process. Modern compilers identify many code issues that may lead to security vulnerabilities. Second, unit tests can identify errors in logic that compilers cannot. Vulnerability scans can identify known attack vectors that may exist. Verification of the completed product can identify unexpected behavior. Finally, automation can be applied to the deployed product through vulnerability scans, event alerting, and intrusion detection..

[Audio] So, do you act now? Or wait. Do you implement secure coding practices from program inception? or do you resolve issues as they appear. Implementing secure coding practices at the beginning of the development lifecycle and continuing through deployment greatly improves chances of detecting defects that may be costly in terms of financial, legal, and personal liability. There have been many instances of attacks and data breaches that, if secure practices were in place and at little cost, would have prevented the loss of billions of dollars in revenue, and the embarrassment of public and private individuals. Information security practices may seem to be an annoyance up front, but the cost of ignoring the issues can be catastrophic..

[Audio] The initial version of this standard only covers ten high-priority software vulnerabilities and should be expanded to cover any known issue that can potentially be exploited to cause financial or personal damage to any individual or organization supported by Green Pace. These efforts should include continuous vulnerability assessments, risk assessments, regulatory compliance assessments, and training of staff in secure development practices, regulatory requirements, and organizational security..

[Audio] Security in the software development lifecycle at Green Pace begins at program inception and continues throughout the software lifetime. Security is maintained through enforcement of coding standards, testing at each stage of development, and continuous monitoring after deployment. Within this lifecycle, the ten core security principles are adhered to in order to provide secure and reliable software products to customers. The Defense in Depth strategy is implemented to provide secure application deployments. The Triple-A strategy is implemented to ensure that only those who need access are granted access to only what is needed and only for the duration required, and that all of their actions are documented..

REFERENCES. (SEI CERT C++) Carnegie Mellon University, Software Engineering Institute. (2023). SEI CERT C++ Coding Standard. https://wiki.sei.cmu.edu/confluence/pages/viewpage.action?pageId=88046682 (SEI CERT C) Carnegie Mellon University, Software Engineering Institute. (2023). SEI CERT C Coding Standard. https://wiki.sei.cmu.edu/confluence/display/c/SEI+CERT+C+Coding+Standard (SEI CERT Java) Carnegie Mellon University, Software Engineering Institute. (2023). SEI CERT Oracle Coding Standard for Java. https://wiki.sei.cmu.edu/confluence/display/java/SEI+CERT+Oracle+Coding+Standard+for+Java (Seacord, 2013) Seacord, R. (2013). Secure Coding in C and C++, 2nd Edition. Addison-Wesley.