Social Network For Security Executives: Network, Learn & Collaborate
In Agile’s fast-paced environment and frequent releases,security reviews and testing sound like an impediment to success. How can you keep up with Agile demands of continuous integration and continuous deployment without abandoning security best practices?
Companies have found the following ten practices helpful to achieve a holistic secure Software Development Life Cycle (SDLC) process in an Agile SaaS world. The approaches taken by these companies follow a basic philosophy: keeping security as simple as possible and remove any unnecessary load from the development team.
(Read more: APT Secrets that Vendors Don't Tell)
1 Be part of the process
Security requirements should be considered as additional development checkpoints. Each benchmark
needs to be achieved before proceeding to the next stage of an Agile process.For each step in Agile, associate a security milestone that needs to be achieved. Start already at the post-release planning to perform a security high-level design. This includes the following aspects:
- Security in code development. For example, inspect the planned application in terms of which APIs are going to be used.
- Security in technologies. Identify technologies that are going to be used. For example, if system testing is performed within a Maven process, security tests should be integrated within this system.
- Security in features. For example, forecast any problems associated with regulations. Say, when tracking cookies are used within a product delivered to the UK then prepare compliance to UK privacy regulations.
2 Enforce your policy by using a security package API in each product
There are two aspects to this stage:
a. Use a security package such as OWASP’s Enterprise Security API (ESAPI)
ESAPI is a toolkit which enables the developers to easily consume various utilities.The toolkit provides a variety of out-of-the box utilities such as validators, encoders, encryptors, and randomizers. By using ESAPI, developers do not need to investigate the best security practices and spend time researching correct implementation methods.Consider hashing, as an example. Instead of relying on the developer to add a hash salt, the salt can
already be implemented as part of the ESAPI configuration. The developer, in turn, is left simply to
consume the provided API.
Particular emphasis should be made on validators because these prevent the most common Web application vulnerabilities, such as SQLi and XSS. Each organization needs to evaluate where to integrate the validators. Some businesses may decide to apply validators on the controller level (e.g. on the
Apache layer or within the Tomcat filter). Other companies prefer to integrate validators within the development code to test each input. While each company needs to decide the right strategy for them, we have found that many companies choose to validate each input within their code. This decision is based on two main reasons:
One organization we worked with took code-level validation one step further. The particular organization implemented a validator that does not return the traditional true/ false boolean values, but rather returns null if the input is invalid. In this manner, the security team was able to prevent developers from mistakenly using that same value later on in the code.
b. Validate that the developers are using the right API
For each input, ensure that the developer uses the right validator as provided by the security team. This entails failure of the security test in case the developer chooses not to use the API. Enforcement can be achieved through source code analysis that is customized to the security team’s requirement.
3 Integrate Source Code Analysis (SCA) within the native process of code management
Enforcing the security policy means that the developers cannot proceed with the build process if the checked in code does not comply with policy. To keep up with the fast-paced development environment, the developers must be able to consume the policy without a long training period.
The way to address this challenge is by integrating SCA within the different stages of the development process. Particular aspects to pay attention to are:
4 Break the build for any “high” or “medium” findings
Do not compromise security by releasing a product that contains any high or medium findings. This requires eliminating the flaw already at the build process. Meaning, if the developer checks in a few
high security bugs, the build will break. Unless the vulnerabilities are fixed, the developer fails to build a package.
(Read more: 5 Security Trends from Defcon 2014 - The Largest Hacker Conference)
5 Use automation to collaborate with the security dynamic test
Dynamic testing within the product can be implemented through positive and negative unit tests.
6 Run a penetration test
Engage both professional and your customers as penetration testers:
7 Engage technology leaders as security champions by showing them the value
Even with large security teams, it is obvious that developers outnumber the security team. To extend security’s outreach, engage with the technology leaders and place them as the security champions. Gaining such cooperation with R&D guarantees that also when security is not physically present, security does come up in each and every scrum meeting.
8 Train developers on a regular basis
The point here is not necessarily to establish a formal training process where developers are sent to a Web application security course. There are other means for training, such as:
9 Provide a collaboration platform for security discussions
This practice goes hand in hand with the previous practice on training developers. The point here is to not only accumulate or disseminate information related to security practices. This practice focuses on establishing a security collaboration platform with the intent of sharing information and raising discussions surrounding security issues.
10 Start small but think big
Many of these practices, especially the practice of breaking the build for any “high” or “medium” finding, requires the management and superiors support. We recognize that gaining this type of trust is not an easy goal to achieve. Various companies have found the following steps helpful:
Progress to the big legacy project. At first, don’t break the build for security findings in this big
project. It is enough at this stage to identify the gaps, close them and create a program of how
development will fix the flaws.
Fix the flaws on the legacy system only after achieving confidence. Fix the flaws on the legacy systems only after understanding how to correctly deliver the security package (such as ESAPI), how to inspect it correctly, and where to correctly apply the validation without any impact to the product.
Proceed to the big project in-making. Naturally, this is the ultimate goal and security should already be integrated within the Agile process. At this step, the validators should already be packaged and set within a single framework.
Disclaimer: This report is from Checkmarx and if you want more details or want to connect you can write to email@example.com
Read more: Technology/Solution Guide for Single Sign-On