Congratulations! You have the idea for the next great app or online business, you have the developers, you have the initial funding and you are good to go. But how do you go about avoiding the mistakes of others and releasing a piece of software (or launching a service) that is secure and won't break apart at the first attack - possibly taking down your business ambitions and customers' trust with it?
The first aspect to note is that there is no such thing as absolute security. As recent revelations around national security agencies, their successes and their failures show even the most well-resourced and legally-privileged organisations fail to secure their data and processes; even the most unlikely sounding exploitation techniques can work and are deployed.
So what is a start-up trying to get things right to do? Ignore security and consequences will follow. Spend too much on security and other business requirements could suffer. Neither approach is right; security should get the right level of attention, not more and not less.
The second thing to note is that defending is always more difficult than attacking; attacking is always easier than defending. An attacker needs to find only one way in; defenders need to defend against many different attacks possibly coming from different directions. And as every business has limited resources, these resources need to be well-spent and focused on addressing the right sort of risks.
Finally, as a start-up, you can’t afford to waste time and effort reinventing the wheel (unless you are in the bicycle business). You need practices that work and deliver more often than not - practices that have been tested and found to work reasonably well - to imitate. Luckily enough when it comes to building security into software and services we have exactly that and what is even better news, it’s free!
The Building Security In Maturity Model (BSIMM) is currently in version 5 and is a culmination of extensive work and research into how 67 industry-leading organisations engineer security of their products and services. Instead of guessing or inventing what should be done, BSIMM asks the questions what is being done and what works. The core of BSIMM is the Software Security Framework that has 4 areas and 112 activities under 12 groups:
| Governance | Intelligence | Touchpoints | Deployment |
|---|---|---|---|
| Strategy and metrics | Attach models | Architecture analysis | Penetration testing |
| Compliance and policy | Security features and design | Code review | Software environment |
| Training | Standards and requirements | Security testing | Configuration and vulnerability management |
Each group has a set of activities that work towards engineering secure software and systems at 3 levels of maturity (Levels 1-3), level 1 being the entry level and level 3 being the highest level of maturity as indicated by research into security engineering practices at the 67 organisations mentioned earlier.
Naturally some security engineering practices are more widely adopted than others but what is perhaps more important to note is that no organisation implements all practices at the same level of maturity: they all pick and choose what is most important, relevant, effective and doable in their circumstances - a down to earth approach that is in contrast with some more prescriptive and rigid approaches.
The purpose of this article is to present just 12 of these activities - one from each group under the Software Security Framework - as a good place to start towards engineering more secure software and systems.
Needless to say picking and choosing 12 out of 112 is a subjective exercise and no doubt different practices can be chosen but my intention is to encourage startups to consider building security in and suggest that BSIMM is a very good place to start. Effectively implement just 12 out of the 112 activities and you are moving in the right direction.
1. Strategy and metrics: Create evangelism role and perform internal marketing (SM1.2)
To release a more secure piece of software or to provide a more secure online service everyone in your organisation needs to buy into the idea that ‘security is a process’ (Bruce Schneier) and that for the process to work everyone needs to play their part. Lip service won’t do - you really need to care about delivering a trustworthy app (or service) - that won’t let down your users and ultimately your business. A named qualified individual needs to take a leadership role and communicate the importance of security practices throughout the organisation - whether it has three members of staff or 300.
2. Compliance and policy: Identify personal data protection (PII) obligations (CP1.2)
There are many different laws and regulations that businesses need to comply with, however few areas of non-compliance have greater potential for damaging the reputation of your business and offending your existing and potential customers than misusing, abusing or failing to protect their personal information. You need to have a very clear understanding of and policy on personal information and have to take effective steps to implement it. The point here is not only to comply with law and regulations but to ensure and assure your existing and potential customers that you actually do.
3. Training: Deliver role-specific advanced curriculum (T1.5)
You have to go well beyond the customary (and usually useless) security awareness courses advising staff to change their passwords and update their AV. The point is not that we can now ignore passwords and AV - the point is that to stay ahead of the game your people need to have the knowledge and skillsets required for the role - a one-size-fits-all solution doesn’t work - and the training needs to actually help your developers develop secure code and services. You need to ensure that especially your developers and technical staff have the right skills and that they are kept up to date.
4. Attack models: Build and maintain a top 10 possible attacks list (AM1.1)
There are many ways to attack software but some attacks are much more likely or have much higher impact than others. Use your business knowledge and professional advice from security professionals to identify a list of Top 10 possible attacks against your application or service to inform the design and implementation of your defences.
5. Security features and design: Engage security with architecture (SFD1.2)
What does this mean? It means stop thinking about security as something you add and start thinking about it as the way you create, develop and implement your product or service. Of course it’s not easy and it doesn’t come free, and has dependencies (not least on T1.5 above), but it is the only way to get it right.
6. Standards and requirements: Use secure coding standards (SR1.4)
Engineering secure systems is a complex challenge, however the 80/20 rule applies. Use industry sources such as OWASP Top 10, CWE, and others to avoid textbook mistakes. Ensure your tailored training links up with these standards and requirements. Print them out and stick them on the wall - 80 per cent return on 20 per cent investment is a good return.
7. Architecture analysis: Perform a security feature review (AA1.1)
Even the best professionals can overlook or forget something - that’s why we have security reviews. When it comes to security reviews there is no replacement for security-specific expertise. What may look like an obviously acceptable security solution to someone not familiar with current security threats may turn out to be flawed or inadequate. Get your designs and architecture reviewed by someone qualified and incorporate the lessons learned to improve your future designs.
8. Code review: Know which bugs matter to you (CR1.1)
Code review may be an expensive and challenging activity - even with the best tools available you are not guaranteed to identify all the bugs in your code. What you can do however is to identify which bugs could cause the most damage to your code and your business and focus specifically on identifying and addressing them. Industry sources such as the above mentioned OWASP Top 10 and CWE are good places to start. This activity is related to AA1.1, SR1.4, T1.5 and AM1.1 above.
9. Security testing: Drive tests with security requirements and security features (ST1.3)
Quality assurance testing must include functional security feature testing. To quote BSIMM: ‘For example, a tester could try to access administrative functionality as an unprivileged user or verify that a user account becomes locked after some number of failed authentication attempts. For the most part, security features can be tested in a similar fashion to other software features. Security mechanisms based on requirements such as account lockout, transaction limitations, entitlements, and so on are also tested.’
10. Penetration testing: Use external penetration testers to find problems (PT1.1)
Penetration testing is one of the most important security assurance activities in BSIMM but unfortunately it is also often misused. Penetration testing does not replace any of the other 11 activity areas nor does a ‘clean’ penetration test report indicate a perfectly secure system or application. A full coverage of penetration testing best practices is outside the scope of this article and the reader is referred to the Buyer’s Guide to Procuring Penetration Testing Services by the Council of Registered Ethical Security Testers (CREST), the accreditation body for penetration testing providers in the UK.
11. Software environment: Ensure host and network security basics are in place (SE1.2)
No matter how good your application is, if it runs on an insecure platform or an uncontrolled network it won’t stay unexploited for long. Host and network security are the foundations that need to be taken care of and infrastructure security underpins application security. To quote BSIMM, ‘Doing software security before network security is like putting on your pants before putting on your underwear’. Using platform as a service (PaaS) or similar services may make things easier but the ultimate responsibility still stays with you - EC2 or Azure won’t magically dissolve all the security challenges.
12. Configuration and vulnerability management: Know what do when something bad happens (CMVM1.1)
Last but not least be prepared to deal with security incidents (including bugs in your software) when they happen, because they will. Software is imperfect and operates in an imperfect world and you need to be able to deal with real and imagined security compromises, curious users, well-meaning security researchers and not-so-well-meaning criminals.
This requires having an incident response plan that works and clear lines of communication - of course in addition to having the technical know-how to address incidents as they arise. Critically, how you seem to deal with security issues in your product or service is not less important than how you really do - therefore you need to get your communications right to reassure existing and potential customers that you do care about security of your product or service and their data and business.
As you can see these twelve activities cover the whole development life cycle and while no doubt much more can and should be done to deliver less insecure software and services these twelve activities are good places to start in your journey towards better software and services for the Information Age.
For a more detailed coverage of these and the remaining 100 activities refer to the source: the BSIMM document is available online to browse and to download as a PDF.
Edgar Danielyan FBCS CITP is Technical Director at JUMPSEC, penetration testing and security architecture consultancy. He is a Council of Registered Ethical Security Testers (CREST) registered technical security architect and penetration tester, as well as a published author.
