7 Tips for Continuous Application Security
Even though most of the security breaches nowadays come from applications, security is still an after thought in companies policies. Still too few resources are dedicated to improve security during the development process and too much in countermeasures once in production. For instance security products, pentests, security code review…
I will begin to publish a new set of articles about what is called Continuous Applications Security or How to Integrate Security Painlessly in a agile and continuous integration process in order to increase significantly the overall security of the application.
The traditional approaches to application security require security experts and simply cannot scale or work at the speed that modern software development now requires. Most application security is largely separate from software development, enforced with “gates,” and creates considerable friction between security and development teams. Since security is an afterthought, security experts often come once the application in production telling all that have been wrong and blaming developers who were not properly trained for that particular matter.
With this method the primary responsibility for security is re-centered on those teams responsible for building, testing, and deploying the applications. The application security experts will move from a punitive role to a more strategic role participating in development process and focused on helping the development team detecting and reacting upon new threats.Respect some Basic Security Rules. The first step is the toughest but the utmost necessary. You need to have basic foundations to iterate over security on your application. First iterations should be about ensuring that these basic security rules are respected:
Passwords are encrypted in the database
The applicative server(Tomcat,Apache,nginx) runs with least privilege
The application database has limited rights (own user, own role)
Limit the verbosity of error messages. Typically server version, stack trace and applicative environment should not be disclosedThe security experts should run few iterations to assess the current state of the application and work necessary to correct the flaws discovered. Ideally he should be able to create stories to put in the backlog(with the consent of the team) of the application in order to correct these defects.
Write security oriented Unit Tests. In most development team, unit testing is already a part of the process of testing and deploying software. The idea here is to add extra case in unit testing that is security oriented. For example, in users creation , the security experts will assert that SQL injection strings returns the proper error message. Hands in hands with the development team the security experts should bring their skills in order to design the proper unit test case : XSS strings, SQL injection strings… Since nowadays the unit testing process is really simple, it will allow the development team to discover about security regression in the product and will help promoting the security culture inside the organization.
Run automatic scanners as the build level. Without investing into security pentesting or code review consultant, there are plenty of free and open-source tool that can be run to discover potential flaws in software. Using a bit of scripting in your Continuous Integration Platform it becomes really simple to integrate security into the build process and give the proper severity to security regression or show stopper. The security expert should work with the deployment team in order to add this step into the build process and configure them properly. They will also be responsible for actively checking the results of such scan, validate false positive and advise the team in case of major security problem discovered during the scans. Example of tools : Rats, Nikto , Google Skipfish, Webscarab, OWASP ZAP,FindBugs,PMD,CheckStyle.
Don’t implement your own security module. Creating their own security module for their software is not a good idea. Security libraries and secure implementations of cryptography algorithm exist in all language and security experts should make their mission to promote the use of such libraries. There is no need to re-invent the wheel, it justs create new possible flaws. Most cryptographic libraries relies on proved maths problem and developers should not consider their own module as secure enough. As much as possible, developers should use libraries and genuine security mechanism available in their language. This includes authorization, authentication, cryptography, input sanitation, session management, proper encoding.
Stay tuned about your product and library. Of course even if you use libraries and framework mechanism, it does not mean you’re completly safe. It is well known that from time to time , new exploit appears and that’s why the development team and security experts should constantly stay tuned about security announcement and events. Most frameworks provide RSS feeds and updates regarding security. The team should build a feed aggregator about the technology they are using in order to stay up to date regarding version and security of their libraries. This can be done using online services such as Netvibes or any other feed aggregator. This could look like THIS which is my public watch list regarding security announcement. You can also find websites specialized in exploits and security vulnerabilities such as Exploit-DB. Security experts should be in charge of creating, maintaining and regularly check on those feeds and communicate properly with development team in order to apply the proper patches.
Think of plan B. Eventually even if you follow all these advices, you will get hacked. It might be with a new unknown exploit or because the attacker was already there when you started implementing your security policy. And then what ? You need a plan B and a documented procedure for some security events that might occur in your application. Here are some cases and scenario you might want to consider :
My application is under a Denial of Service
The database has been compromised with all the customer information? Can you reset all passwords ? Is there more sensitive information? Did the attacker spread further than this single database ?
XSS are displayed to our customer and our website could be used in a scam/phishing campaign
Continuously challenge your application security process. These rules are not written in stone, and the essence of iteration is to constantly be ready to adapt new events. Once you have established these processes , you should continuously challenge your infrastructure to see if you can do better. Can you handle the detection of new attacks ? Can you include security more deeply into your recipes of deployment ? Are there better tools to scan application and match your needs ? It is also always a good thing to bring the initiative to brainstorm with the development team. They might have ideas you never thought of and that are quick-win. It will also help you understand their point of view regarding security and the feasability of your measures.
Regarding the role of security experts in this process, they will be responsible for implementing, maintaining and consulting the data collected from these measures. Ideally they will be backed up by the SCRUM master or any other person in charge of keeping the rules of agile development and continous integration.
Instead of being the guy who complains at the delivery of the project and always try to keep up with the new security flaws, security should be intrinsically coupled in the development process and at some point become natural to the all team as continous integration and agile development are.
