Embedding Security Into Software During Development 

Security has traditionally been focused at the infrastructure level, particularly at the edge of the network where traffic flows across trusted and untrusted network segments. This is accomplished by using various tools such as network or application specific firewalls (e.g. web application firewalls, or email gateways) that would analyze traffic and look for malicious payloads. In addition, vulnerability scanners, intrusion and malware detection tools have been used to scan for suspicious content or activity, raising alerts or at best resulting in some form of blockage or quarantine.

These controls act from outside of the application and do not have the visibility from the inside required to truly understand what is taking place or whether the perceived attack was successful or not. For example, an IDS or vulnerability scanner may observe a security issue based on the configured rules or attack signatures and raise an alert, however, due to a lack of a view from within the application, such tools cannot determine with 100% certainty as to whether the attack succeeded or not. Having an internal view from within paints the most accurate picture of potential security issues, as opposed to an outsider view which is a good guess at best.

In addition, statistics have shown that bolting security as an afterthought to the application is more expensive than taking security controls into consideration early on and “baking” them in. Applications should be architected and designed with security in mind, where all possible threat scenarios are considered and mitigating controls as well as compliance requirements are built-in. In doing so, more secure applications are produced, costly inefficiencies are avoided, and organizations receive a better return on their investment.

This does not mean that security controls outside of the application are not needed, as security should follow a defense in depth approach and be applied at all layers where possible.

HOW TO BUILD SECURITY INTO THE DEVELOPMENT LIFECYCLE

Time and time again, organizations ask us: “How can security be incorporated into the application development process?” The answer does not lie in hiring a security team member to perform all security tasks. The solution is to cover security holistically across the following three pillars:

1. People. Developing and operating an app securely always starts with the people behind it. Promoting a security mindset at all stages breaks down silos and creates a culture of accountability. Everyone involved should be enabled to address security at all stages, rather than having security act as gatekeepers.

An existing team member should be appointed as the Security Champion within each team to act as the primary for security tasks. This Champion should support others within the team and address low-hanging fruit (more on that later). These individuals should receive relevant training and support from a security team who can be internal or external, depending on the size of the organization. While large companies typically have their own application and cloud security teams, small- and medium-sized organizations will find it more cost-effective to work with an outside security services provider.

2. Process. Incorporating well defined security policies, requirements, and related processes within the development process creates a flow that achieves the desired security goals without introducing delays and additional cost. A secure development process should include:

  • Incorporating well defined security requirements, aligned with OWASP’s Application Security Verification Standard (ASVS);
  • Integrating security design reviews and threat modelling at different stages of the application lifecycle;
  • Determining how issues are addressed without slowing down the development and deployment processes;
  • Identifying areas of weakness at all stages and setting up a feedback loop to continually improve the app’s security; and
  • Providing regular security training opportunities to the team such as OWASP Top 10. Consider using the Security Knowledge Framework, and the OWASP DevSlop project, containing several modules with the goal of teaching DevSecOps to participants.

3. Technology. Tools can assist your people and support your processes. The goal is to speed up the release cycle by using tools to automate security testing and reduce dependency on manual methods as much as possible. However, automated tools are only able to identify the “low-hanging fruit” and cover less than half of verification requirements outlined in ASVS. As a result, manual assessments are still required periodically, particularly as related to access control and business logic flaws.

At a minimum, the following automated security test activities should take place during build and deployment phases:

In addition, it is also important to address the security of the app while in operation by incorporating security tools such as:

You can find a list of free for open source security tools that cover the above areas of concern at this OWASP project.

Summary

In conclusion, “baking” security into the application and having an insider real-time view from within can provide an accurate picture, allow enforcement of the required policies, and assist in maintaining inventory and addressing vulnerable packages as early as possible. Addressing security by enabling your team, putting well defined processes in place, and automating as much as possible using technology, along with proper support from a security team, will put you on the path towards building secure applications. This will help protect your business  from cyberattacks, reduce costs and speed up the release-to-market process.

Menu