cns - hut3 - information assurance - secure development

Secure Development 10th December 2013

cnsgroup.co.uk December 2013

Agenda

•  The Common Security Model

•  Why it’s a Problem.

•  Secure Development Life Cycle

•  Questions


The Common Security Model Project Managers Security Developers Security IT Security Managers Security


Project Managers Security

•  Project Managers know they need to consider security, the security officer told them so.

•  They are told they need a Pen Test.

•  Pen Tests are scheduled at the end of the project just before Launch.

•  Pen Tests are usually urgent

•  Pen Tests are usually very short and compressed time scales.

•  The Pen Testers Usually find serious issues.

•  The report is given to the developers.

•  The Launch is Delayed.

•  The Vendors Charge the Client to Fix it.

•  The Client Presumes it is fixed and therefore secure.


Developers Security

•  Developers Develop to Specifications. If The Specification does not Specify Security, you wont get security.

•  Developers are working under huge time pressures.

•  Developers are o#en remote and never meet the client.

•  Developers don’t know the business, what it does, how it works or how this product fits in.

•  If Pen Testers find issues, Developers will fix them but will in most cases see it as a new feature or function and charge client for it.


IT Security Managers Security

•  They are formally trained and experienced.

•  They know what security is.

•  They are massively understaffed.

•  They need to deal with the big picture of risk for the whole organisation.

•  They don’t have time to design security into the applications.

•  They rely on testing and fixes.


What is wrong with that Model?

•  The same mistakes are made every time.(For companies where we do lots of tests, we frequently find the same issues!)

•  Companies are paying for substandard code and applications.(You wouldn't’t pay for a new car that failed its MOT)

•  Security is being measured against other peoples standards not the clients.(Your relying on your Vendors/Developers to build security but they don’t know what you mean by security)

•  Application Security is not improving.

•  Money is being spent but not achieving value.(Its been spent on buying apps, testing them, fixing them, testing them, fixing them etc)


The Solution

•  SDLC – Secure Development Life Cycle

•  Design Security in at the beginning.

•  See Security as a feature.

•  Actually Improve Security.


Stage 1 - Definitions

•  Organisations need to define what they mean by security (its not that obvious)

•  What threats worry you (e.g a Bank and a Consultancy have different concerns)?

•  What standards and regulations do you need to meet?

•  What is your security history, e.g What mistakes do you keep making, what incidents do you have.

•  What threats are relevant to your sector, what are the trends.

•  A High Level Document

•  And a very technical standards document.


Prototyping and Design

•  Security Definitions need to be part of the functional design, unless you tell programmers that passwords are needed and how they should be stored it wont happen.

•  When a design is completed, it is reviewed by security specialists who know the organisation but are independent of this project.

•  Design is compared to security definitions and rejected if it does not explicitly meet the security requirements.

•  This should not be painful, the requirements should be useable on most projects with little or no change.


Technical Risk and Review

•  Coders produce code, to the technical specification and inline with the organisations general coding standard.

•  Code is reviewed (even if its just changes and updates), mixture of manual review and automated tools.

•  Code is rejected until it is correct.

•  Application is tested independently of developers, this includes general security but also specific threat scenarios.

•  Any issues identified push the code back to the developers and Design and Specification, the process is repeated.(Vital to understand how the failure occurred, was it a bad spec or bad code)


Output

•  Its not just about fixing issues, its about learning from them and fixing the route causes.

•  Some risks are accepted, but they need to be documented and understood.

•  Lessons learned need to be fed back into security definitions and policies (to prevent the issues happening again)

•  Release or Don’t Release code/application. Needs to be a structured decision not just instinct or business need.


Conclusion

•  A proper SDLC is usually cheaper.

•  Less mistakes are made.

•  Less tests are needed.

•  Less fixes are needed.

•  Less risk is carried.

cns - hut3 - information assurance - secure development

Technology