Securing apps is a major challenge and achievement for any organization. For an app to be secure, it should not only be developed securely, but the entire lifecycle must have infusions of security. I use the word ‘infusions’ because the concept of ‘controls’ and ‘requirements’ seems highly cumbersome.Nevertheless, Security in Applications can be quite difficult to grasp. Try reading any documents around “Secure Software Development Life cycle” or “Secure SDLC” and you will find your head spin with words like “Threat Modeling”, “STRIDE”, “Trust Boundaries”, so on and so forth. Many people I meet are overwhelmed by any talk of security in apps, as a result. If you google “Application Security Maturity Model” or something similar, you would need a lot of coffee trying to get through these documents.
Keeping that in mind and taking inspiration from Joel Spolsky’s 12 steps, I have created a quick and dirty ‘checklist’ of sorts for building secure apps. Now keep in mind that this is a simple ‘Yes’ or ‘No’ test. The idea is that you go over this checklist and make mental answers of ‘Yes’ or ‘No’ as you go along. If you find that your scores are below 7, then you need to fix some of the deficient items in your application security processes/practices. If your score is 8 and above, then you can be sure you are in decent shape, with some room for improvement. Similarly, if you are at 2 or 3, then your application security practices need serious intervention. So, without further ado, let’s get into it.
Abhay’s 10 Step Secure App Test
- Do you include security requirements other than “authentication” in your Initial Requirements spec?
- During interviews, do your developers answers questions on security like “Protection against SQL Injection or CSRF”?
- Do you do hybrid security testing?
- Do you do security code reviews, at least once a year?
- Apart from Use-cases, do you create “Abuse cases”?
- Do you subscribe to security feeds from your application platform(s)?
- Do you do a security check for each release?
- Are your devs and architects trained on application security?
- Do you maintain a Secure Coding Standard for your Developers?
- Does your management understand/appreciate the impact of an application security breach?
1. Do you include security requirements other than “authentication” in your Initial Requirements spec?
Most companies creating software would have software specifications. Call it what you will (I have heard of documents from High Level Document, Requirements Document, Design Spec, etc), very loosely, a document of this nature provides some input into the functionality of the application and the key components of the application. This is typically done at the Requirements gathering phase for each project or sprint (in case its AGILE, etc). If your document contains basic security requirements like authentication, with statements like “Application shall have unique usernames and passwords” or basic authorization with statements like, “Application shall enforce permissions and privileges based on Role Based Access Controls”, then the document grossly under-represents application security needs. Application Security has several areas that need to be included, even at a high level or in a Requirements document. Aspects of Logging and Correlation, Encryption (with specifics), Sensitive Data protection requirements, secure coding requirements and so on must be included in the Application’s requirement document or initial spec.
2. During interviews, do your developers answers questions on security like “Protection against SQL Injection or CSRF”?
Technical questions or a “show and tell” style of interviews are important when hiring developers. Developers are asked a series of questions and sometimes, even required to write some proof of concept code to show their skills in developing apps. Security is equally important. If your developers don’t know what a “Host Header Injection” attack or “Cross Site Request Forgery” is, they can’t possibly be expected to develop an app that is resilient against modern attacks. Developers already have tight schedules and delivery timelines. Lack of basic application security skills (especially in the platform of their competence) only exacerbates issues for your application’s security. I strongly believe that developer interviews and technical discussions must have a generous peppering of application security related questions like the OWASP Top 10 Flaws or similar.
3. Do you do hybrid security testing?
I have seen several companies that put their application through an automated app sec vulnerability scanner and to go production after the scanner has thrown a clean report. This is not nearly enough. With apps getting more complex (RIA frameworks, web services, middleware, caching, queuing, etc), the need for both manual and automated security testing (called Hybrid testing) has increased. A skilled penetration tester can find way more issues than an automated vulnerability scanner can. If you are only using an application security vulnerability scanner (not not using anything at all), you should seriously consider a hybrid application security test (penetration test).
4. Do you do security code reviews, at least once a year?
Penetration Tests are useful. Extremely useful. However, security code reviews are essential to securing applications. Security Code Reviews could be peer-reviewed, with a static/dynamic code review, or expert reviewed. Either way, the important thing is that risky code is being evaluated and red-flagged for developers to fix.
5. Apart from Use-cases, do you create “Abuse cases”?
A Use case is a scenario that represents a user’s interaction with a system and steps of said interaction. This is something that most of use in the world of software. An Abuse case is a scenario that represents a user’s (attacker’s) attempt to compromise the app. Abuse cases are detailed threat scenarios that represent possible attacks that might lead to an application getting compromised (from a Confidentiality, Integrity and Availability perspective). This is essentially what Threat Modeling is all about. Threat Modeling is a practice of identifying threats, vulnerabilities and attack scenarios that could affect your application. Security controls and countermeasures are identified and chosen based on these threat models.
6. Do you subscribe to security feeds from your application platform(s)?
Platform code, External libraries and API forms the bedrock of most modern applications. However, often these components are affected by pernicious vulnerabilities that can have widespread consequences (think Heartbleed, POODLE, Shellshock, Mass Assignment, or something as simple as a vulnerable WordPress Plugin). Its important that you have information about vulnerabilities in your application’s platform and dependencies in a timely manner. You can subscribe to security feeds from your local CERT (like the US CERT or India CERT), MITRE, NVD or from a security update service like Sucuri.
7. Do you do a security check for each release?
In my experience, each product release has the potential to introduce new security issues and vulnerabilities. Some companies never emerge from the chakravyooha(maze) of security vulnerabilities and their security woes go around in circles. This is primarily because they do not incrementally test releases for vulnerabilities. Security testing for releases not only reduces the burden on the developers, but makes application security a focused and iterative process that is achievable and certain. Just like you would do functional testing or integration testing for a release, security testing per release would make your life a whole lot easier.
8. Are your devs and architects trained on application security?
This extends from point 2, but differs in some ways. It is not only important for your developers and architects to be aware of application security concepts and practices, they need to be trained periodically on these concepts and practices. Application Security is constantly evolving, with newer attacks and vulnerabilities being identified by researchers and blackhats all over the world. Your developers and architects have to be formally trained on application security, either workshop style or through a series of training capsules.
9. Do you maintain a Secure Coding Standard for your Developers?
A famous line from the movie, “The Ten Commandments” is “So it shall be written, so it shall be done”. This dialogue was probably written by a QA guy somewhere. But jokes aside, this is important. A Secure Coding Standard is an essential guide for your developers. For newer members of your development team, this becomes a valuable introduction to your company’s security coding practices and application security practices. For experienced developers, this is a great guide to follow and enforce consistency across the lifecycle. A secure coding standard should convey the coding practices that your developers should follow for I/O operations, Input Validation, Encryption and Integrity, Output Encoding, Request Authentication, Authorization checks and so on.
10. Does your management understand/appreciate the impact of an application security breach?
One of the worst things that can happen to your company is to have management that does not understand/appreciate the impact of application security breaches. Application Security and Information Security are top-down practices that begin in the boardroom. Management that is not aware or concerned with application security results in a company that would probably end up being a breach statistic.
Abhay Bhargav
Abhay is an Information Security evangelist. He has authored “PCI Compliance, a Definitive Guide” published by CRC Press New York. Abhay is also a regular speaker in Industry events including OWASP, Oracle OpenWorld, JavaOne, ISACA, NASSCOM and so on. He has performed security assessments for enterprises across domains of Banking, ITES and Telecom and also led security assessments for the Payment Card Industry Compliance (PCI-DSS) as a QSA.
