How to build security into Software Development?

Historically, companies have focused on implementing security controls around physical infrastructure, networks, servers and endpoints. This focus is potentially because many different technological solutions exist to help to protect these assets which can be managed in a centralized way using dashboards and remote consoles.

Examples of these kinds of solutions include next generation firewalls, anti-virus and advanced threat protection (ATP) tools, and Security Incident and Event Monitoring (SIEM) supported by threat intelligence processes.

However, the maturity level of security in the software development lifecycle (SDLC) remains some steps behind and I believe there are a few reasons for this.

Lack of time and the need to meet a deadline is always the first complaint when discussing implementing security controls beyond those which are default features in development frameworks, (for example).

The second complaint is around budget, especially if the development team is outsourced and are billing by the hour. Since security has not historically been considered a basic property of software code in the same way that performance and readability would be, it is still seen as an extra cost.

The third complaint is the lack of knowledge of many developers about basic security controls and the impact of the major security flaws already documented by security community. Hopefully all developers know about attacks such as SQL Injection, Cross-Site Scripting, Session Hijacking, etc. However, is quite clear that sometimes developers are missing the deep knowledge about the real consequences of successful exploitation of those flaws. For example, a developer may know that a SQL Injection attack may lead to data being stolen from a database but not be aware of other risks posed by the same attack such as getting a remote command shell on the server where the vulnerable database is hosted.

There are other examples of barriers to implementing a secure software development lifecycle, but with the increase in data breaches related to application vulnerabilities and the rise of known penalties such as those defined by GDPR, it is now easier to demonstrate the business case for companies to increase the maturity level of their secure development processes.

OWASP (the Open Web Application Security Project) is an international non-profit organization dedicated to application security. It provides very valuable resources ranging from tools to frameworks to documentation, all developed by a dedicated network of volunteers from around the world. Nowadays, it is the best repository where you can find all the information needed to raise the level of knowledge and skill of your technical and management teams.

The OWASP Top 10, for example, which is updated roughly every three years, is an excellent document to build awareness of the most common application vulnerabilities which have been noted in the last few years and the right controls and mitigations which can be used to avoid and fix them. However, it is clear that it is vital that security is included as early in the SLDC as possible since the later that security is introduced, the more expensive issues are to fix. The Top 10 project is probably not the most ideal project for including security early on in the SDLC nor is it comprehensive enough to help an organization reshape their SLDC to include security at each stage.

As such, I would like to discuss the OWASP Software Assurance Maturity Model (SAMM) project. This is an open framework to help organizations formulate and implement a strategy for software security that is tailored to the specific risks facing the organization. This model defines four different Business Functions related to Software Development Lifecycle which the organization needs to address: Governance, Construction, Verification and Deployment.

These four Business Functions can be divided in 12 different Security Practices:

·       Governance (Business Function)

o   Strategy & Metrics (Security Practices)

o   Policy & Compliance (Security Practices)

o   Education & Guidance (Security Practices)

·       Construction (Business Function)

o   Threat Assessment (Security Practices)

o   Security Requirements (Security Practices)

o   Secure Architecture (Security Practices)

·       Verification (Business Function)

o   Design Review (Security Practices)

o   Code Review (Security Practices)

o   Security Testing (Security Practices)

·       Deployment (Business Function)

o   Vulnerability Management (Security Practices)

o   Environment Hardening (Security Practices)

o   Operational Enablement (Security Practices)

These twelve security practices can each help to increase the maturity level of the organization’s SDLC, in a measurable way. Implementing these practices can be planned step by step and the resulting changes and improvements can be monitored. Therefore, it represents a complete process that can be integrated into the SDLC and ensures that security is considered from the very first stages of the planning through to the application being deployed to production and on through the post-deployment phase as well, with ongoing vulnerability management as a continuous practice.

The activities related to each security practice are listed below:

·       Governance

o   Strategy & Metrics

§  Estimate overall business risk profile

§  Build and maintain assurance program roadmap

§  Classify data and applications based on business risk

§  Establish and measure per-classification security goals

§  Conduct periodic industry-wide cost comparisons

§  Collect metrics for historic security spend

o   Policy & Compliance

§  Identify and monitor external compliance drivers

§  Build and maintain compliance guidelines

§  Build policies and standards for security and compliance

§  Establish project audit practice

§  Create compliance gates for projects

§  Adopt solution for audit data collection

o   Education & Guidance

§  Conduct technical security awareness training

§  Build and maintain technical guidelines

§  Conduct role-specific application security training

§  Utilize security coaches to enhance project teams

§  Create formal application security support portal

§  Establish role-based examination/certification

·       Construction

o   Threat Assessment

§  Build and maintain application-specific threat models

§  Develop attacker profile from software architecture

§  Build and maintain abuse-care models per project

§  Adopt a weighting system for measurement of threats

§  Explicitly evaluate risk from third-party components

§  Elaborate threat models with compensating controls

o   Security Requirements

§  Derive security requirements from business functionality

§  Evaluate security and compliance guidance for requirements

§  Build an access controls matrix for resources and capabilities

§  Specify security requirements based on known risks

§  Build security requirements into supplier agreements

§  Expand audit program for security requirements

o   Secure Architecture

§  Maintain list of recommended software frameworks

§  Explicitly apply security principles to design

§  Identify and promote security services and infrastructure

§  Identify security design patterns from architecture

§  Establish formal reference architectures and platforms

§  Validate usage of frameworks, patterns and platforms

·       Verification

o   Design Review

§  Identify software attack surface

§  Analyze design against known security requirements

§  Inspect for complete provision of security mechanisms

§  Deploy design review services for project teams

§  Develop data-flow diagrams for sensitive resources

§  Establish releases gates for design review

o   Code Review

§  Create review checklists from known security requirements

§  Perform point-review of high-risk code

§  Utilize automated code analysis tools

§  Integrate code analysis into development process

§  Customize code analysis for application-specific concerns

§  Establish release gates for code review

o   Security Testing

§  Derive test cases from known security requirements

§  Conduct penetration testing on software releases

§  Utilize automated security testing tools

§  Integrate security testing into development process

§  Employ application-specific security testing automation

§  Establish release gates for security testing

·       Deployment

o   Vulnerability Management

§  Identify point of contact for security issues

§  Create informal security response team

§  Establish consistent incident response process

§  Adopt a security issue disclosure process

§  Conduct root cause analysis for incidents

§  Collect per-incident metrics

o   Environment Hardening

§  Maintain operational environment specification

§  Identify and install critical security upgrades and patches

§  Establish routine patch management process

§  Monitor baseline environment configuration status

§  Identify and deploy relevant operations protection tools

§  Expand audit program for environment configuration

o   Operational Enablement

§  Capture critical security information for deployment

§  Document procedures for typical application alerts

§  Create per-release change management procedures

§  Maintain formal operational security guides

§  Expand audit program for operational information

§  Perform code signing for application components

Whilst there are a lot of activities to implement here, it is important to execute at the correct pace. If activities are implemented too fast without monitoring metrics to check if each phase was successful and has been integrated into the organization’s processes, the implementation will ultimately fail and the security and other value benefits will not be realized.

It is particularly important to note that the activities in each security practice are ordered based on maturity meaning that an organization should initially focus on implementing the first activities across all the different practices and then once these initial activities are operating correctly, go back and start implementing the next activities, again across each the twelve practices.

The SAMM project documentation even provides metrics for each activity, staff needed and the estimated time that will be required per year for each member of the team to help the end-user ensure that they are implementing each activity in the correct way.

Note that SAMM isn’t the only methodology that can be used to improve the maturity level of a secure development process. Some examples of similar methodologies are BSIMM, ISMM (for IoT environments) or DASMM, this last one representing the implementation a combination of controls from both BSIMM and SAMM at the same time.

Independent of the methodology, is important to understand that everything must be grounded in the solid foundations of a good strategy, metrics to monitor performance and policies and procedures sponsored by management to ensure compliance with the new processes.

Ultimately, the key to success will be employee education to help everyone to understand the real need to improve the maturity level of secure development and to keep everyone updated and aware of their own role in the process.

Always remember to carefully monitor the entire process and establish SMART (Specific, Measureable, Achievable, Relevant, Timely) goals for each step. A good approach to adopt to help with the transformation is the Objectives and key results (OKR) methodology as this will make it easier to identify what needs to be achieved at each stage and what result is expected. The information for this is already provided by the SAMM methodology. There is a link to information on OKR in the references section.

Increasing the maturity of your Secure SDLC will be hard work, but the results should be worthwhile and be shown by an improvement in penetration testing results and decrease reduction in the risk of compromise via application vulnerabilities.

References:

OWASP – https://owasp.org

Open SAMM - https://www.owasp.org/index.php/OWASP_SAMM_Project

BSIMM - https://www.bsimm.com/

ISMM - https://www.iiconsortium.org/pdf/SMM_Description_and_Intended_Use_2018-04-09.pdf

OKR - https://en.wikipedia.org/wiki/OKR

DASMM - https://duo.com/blog/rsac-2018-building-a-software-security-maturity-program

What Application Security teams can learn from the Facebook breach

Background

On 28 September 2018, Facebook disclosed that they had discovered three vulnerabilities in their platform. They were subsequently able to determine that an attacker had exploited the combination of these vulnerabilities and this led to the disclosure of profile information of around 30 million of their users to the attacker.

Facebook have been relatively transparent about what they have found in two detailed blog-posts although the end result, the theft of access tokens, has wide ranging implications including affecting 3rd party web sites where a user uses their Facebook account to login. It was also suggested that the access tokens could be misused to affect 3rd party sites which a user had not used Facebook to login but which had configured in a certain way, allowing the attacker to create that link and login to the 3rd party site.

Facebook gave a detailed explanation of each of the three bugs in their blog-post but they boil down to the following:

1. Missing authorisation on one out of a whole set of possible actions in a particular feature.
2. Access token generated with incorrect permissions.
3. Access token generated for incorrect user.

Whilst it is possible with the benefit of hindsight to see ways in which these issues could have been detected, there are a few important points to consider.

The challenge of business logic bugs

Bugs and vulnerabilities are always going to exist in code. Certain types of bugs such as Cross-site Scripting (XSS) or SQL Injection (SQLi) tend to follow a certain pattern which doesn’t rely on how the site works and are therefore easier to identify and prevent using standard secure development life-cycle controls such as static analysis or automated or manual dynamic testing (for example Burp scanner or a manual tester performing Application Security testing). Additionally, there may be ways of detecting these issues at run-time such as the report flag of the X-XSS-Protection header or alternatively a Web Application Firewall (WAF) which looks for suspicious content in requests.

However, vulnerabilities related to business logic (which applies to all three of the above issues) may not be immediately obvious and will be very hard to identify and prevent using any form of automated technique. They will also be hard to detect at run-time using any sort of pattern matching rule as they will generally not show an obvious pattern.

Another important point is that the number of bugs/vulnerabilities is going to be in proportion to the size and the complexity of the application. Facebook is clearly a very complex platform but it is certainly not the only organisation with this level of complexity.

Facebook has a highly skilled security team, a mature application security program and a well-developed bug bounty programme. They even went to the trouble of creating an entire test version of their application which ethical hackers can use to experiment and look for security vulnerabilities. Whilst they were unable to prevent this incident from occurring, the maturity of their application security programme meant that they were still able to detect and remediate the issue, despite the vulnerabilities being business logic bugs.

Detection at the application level

The OWASP (Open Web Application Security Project) Top 10 Most Critical Web Application Security Risks project provides a list of the most common and concerning web application security risks based on data and feedback provided by the application security community. The 2017 release included a number of new items, one of which was “Insufficient Logging and Monitoring”. The 2018 release of the OWASP Top 10 Proactive Controls project similarly includes “Implement Security Logging and Monitoring” as item number 9.

This brings us to the reason that Facebook were able to report this incident in the first place. Facebook have application level monitoring through which they noted the unusually high volume of token activity. This led to them carrying out an investigation which ultimately led to them detecting the attack. Interestingly, Facebook also have much more granular monitoring (which they have published information about here) which is designed to detect permission issues on an individual basis but this did not appear to catch the issue. Nevertheless, the fact that they had multiple layers of monitoring meant that they still detected the issue.

Advice on application level monitoring

We would strongly recommend that the key lesson which organisations should be taking from this incident is the importance of having a programme of implementing application level monitoring and continually improving and refining this process.

Organisations should start by instrumenting sensitive operations within the system such as when security validations fail or authentication and authorisation actions. The OWASP AppSensor project provides some ideas of the types of events and actions which should be monitored and recorded. A Web Application Firewall (WAF) may provide some of this functionality but it is unlikely to be able to capture business logic specific events.

The organisation should then start creating alerting rules around the events which have been captured based on how suspicious or dangerous they are. As a simple example, for something like an incorrect login, an alert may only be raised after a number of attempts. However, for something like an invalid value for a client-side validated field sent to a web API which would be a clear indicator of someone attempting to subvert the functionality, the alert may occur after only one incidence.

The organisation can then decide how these alerts will be received and consider proactive steps to take in response. This could range from just informing the operations team to throttling the connection with the suspicious activity. The application could even block particular users or sources or disable certain sensitive operations for them or for all users.

All of this activity should be implemented on an incremental basis whereby monitoring, alerts and actions are implemented on a gradual basis so as to assess the impact and benefit at each stage.

Conclusion

Many organisations have network or infrastructure level monitoring but this will only be able to detect a network or infrastructure level attack. This monitoring is still important but it will be completely unable to detect an application business logic attack of the sort experienced by Facebook. By investing in application level monitoring as well, even on an incremental basis, organisations will be in a far better position to detect these types of application level attacks.

This is a really interesting topic so if you want to discuss further, please feel free to get in touch using the details below. I hope to produce some more specific and detailed resources and guidance on this in the future.

Josh Grossman

Senior Information Security Consultant and Team Leader

@JoshCGrossman

joshg@comsecglobal.com

Thanks to Mikael Levy for reviewing and providing feedback on this post.