Developer engagement..

Following my recent posts covering application security and patching, another recent hot topic of conversation has been around developer engagement.  Specifically how to ensure developers are fully engaged in the secure development process.

Much like many current patching processes an issue with a lot of secure development programs is that they are still very ‘push’ focussed.

This approach can be successful, especially for organisations with less security maturity.  I have personally seen great uptake in the use of secure development tools and processes through my current teams work.  However while taking the ‘push’ approach can dramatically improve your application security processes, it does have limitations.

These limitations include;

  • It is very resource intensive for the Security Team – they constantly have to ‘push’ to get developers using the tools and processes and on-boarding new applications and developers etc.
  • It can lead to a culture of secure development being the responsibility of the security team rather than the development teams – a culture of taking rather than owning security
  • Things, including entire applications can be missed.  The security team can struggle to know every application and development project that is in the environment if the onus is on them to push security to every application.  This is especially true in more complex, multinational organisations
  • This focus can also lead to dissatisfaction and higher churn in your security team as you will have skilled application security professionals spending large amounts of their time on-boarding developers and applications, and chasing development teams to understand what is being worked on

So, how can we fix this and ensure the secure development practices from training through threat modelling and code reviews are embedded into the development process?

If you read my post on patching, my key thought will not surprise you!  Developers and development teams need to have responsibility for secure development as one of their key objectives.

This is a fundamental shift in culture and responsibilities.  In order to be successful you’ll need to work to drive support from executives as well as the development teams and their managers.  However if you can enable this culture shift, you will have made a huge difference to the uptake and success of your application security programme.

This shift will change the responsibility for ensuring developers are enrolled on the training platform and added to the code analysis tooling into the development teams.  It will also drive the use of the security tooling as one of their key objectives.  There are two key benefits of this approach;

  • Coverage; The development teams and their management will be bought into the benefits and requirements for security.  This will drive the use of security tools and processes for all in scope developers and applications.
  • Enterprise security can focus on security.  The skilled application security specialists in your team will now be able to focus much more on working with the development teams to support secure design and coding.  The secondary benefit of this is that your team will be more engaged doing the work they want to rather than chasing developers to on-board them and their applications!

The second thing I would recommend to support this approach is the creation of ‘security champions’ within the various development teams.  This would likely not be a distinct role, but rather existing developers who ideally have an abiding interest in security.

These roles will have the responsibility of having a strong understand of the required security processes and tooling, along with fostering a close working relationship with the application security team in enterprise security.  These roles could also help with the development of secure coding guidelines and ensuring the application security team understand the way the developers work and challenges they face.

To support the role and working relationship, security champions having ‘dotted line’ reporting to the application security director (or equivalent) should be considered.

The final piece of the puzzle is to ensure your application security team understands the various development processes in use across your organisation.  While the same level of engagement, similar tooling and processes will be used regardless, how they are applied is likely to vary considerably across different development and support styles.

To be successfully integrated the application security team must consider how to best integrate with Waterfall, the various ‘flavours’ of Agile, DevOps etc.  While you do not want a million different processes you’ll likely need a few to cope with the different development and project processes.

If it is not yet in place for your organisation, a good starting point for the SDL (Secure Development Lifecycle) and the steps it should contain is the Microsoft SDL

https://www.microsoft.com/en-us/sdl/

To help you consider variations of your process for different methodologies they also have an agile version;

https://www.microsoft.com/en-us/SDL/Discover/sdlagile.aspx

Let me know what you think of these ideas, and how you get on with implementing them on your organisation, if you are not doing so already!

K

Why does the OWASP top 10 never change?

Or very rarely?

Subtext, how should we work to create more secure applications?

The OWASP top to remains largely unchanged over long periods of time.  We still see high profile breaches like Talk Talk caused by easy to protect against application attacks.  These fact imply many organisations are still failing to do ‘application security’ properly.

So why is application / development security so hard?  OR is it?

I think application security has historically had similar problems to other areas of security.  It is not seen as a business imperative, so business needs, new features, meeting client requests etc. all supersede security requirements in the priority list.

For many of us this is clearly not news.  However, given the number of incidents that still occur, it is clearly not a problem that has been solved.

For me solving this falls into 3 key areas;

  • Board level buy in for security, and specifically security throughout the development lifecycle – SDLC (Software / Systems Development Lifecycle).  This will ensure there is support for the costs and time associated with delivering a secure development programme.
  • Buy-in from the development teams.  Work with them to ensure they understand the reasons for, and benefits of secure development.
  • Making security part of the SDLC, by ensuring that the relevant tasks and processes are embedded as part of the standard lifecycle.  This will also ensure they are audited as part of that process.

I’ve spoken about board / exec by in for security before, and will do again.  There will also be another post in this series covering developer buy in as that is key to the process being successful.

The rest of this post will cover the areas that I think need to be covered in through the process in order to ensure the development process is as secure as possible.

Where these steps fall, how they are implemented, and how they are checked / monitored will vary from organisation to organisation.  They will also depend on the development processes in place such as Waterfall and Agile variants.

At a high level, these steps are;

  1. Requirements including security requirements
  2. Secure designs
  3. Threat modelling
  4. Static code analysis
  5. Peer code review – focus on quality and maintainability not just ‘pure’ security
  6. Dynamic application analysis / web application scanning
  7. Penetration testing
  8. Associated processes – found flaws are fixed at each stage of the process
  9. Clear risk assessment and ownership processes
  10. Developer Training

 

Requirements, including security requirements.

Any project must have some requirements.  These are what enable us to answer the question ‘what problem am I solving?’.  This also applies to BAU (Business As Usual) type development that may not fall under the project processes.

These requirements need to include the non-functional areas as well, of which security is one.  Security requirements should be as standardised as as much as possible to minimise the effort, and tailored as part of any project or work initiation phase.  To support this, ensure your application security team is closely embedded with the project teams, business analysts and developers.

Secure Designs

While this is more of a statement than process, I have included it to highlight that security teams need to be involved throughout the design process.  I would also recommend that security should be an approver of system and application designs.  This will ensure that meet security policies and requirements as well as meeting secure design principles.

Threat Modelling

This is the process of reviewing a system and assessing any potential threats to it, along with how to counter those threats.  The earlier in the process this can be accomplished the better as it allows the designers and developers to work with the potential threats in mind.  Although either an existing system, or at least a high level design is required to make this worthwhile.

I am personally a huge fan of threat modelling as it has multiple benefits for relatively low cost / effort;

  • More secure designs and development as the teams working on the solution will have a better understanding of the threats, and how to counter them.
  • A better understanding of the system, one of the artefacts from threat modelling is the DFD (Data Flow Diagram).  How many systems in your organisation have have detailed DFDs?  This fills that gap.
  • Under the radar security awareness training.  Without labelling it training, the security team gets to spend a decent amount of time with the design and development teams talking about threats to a system, the consequences if these threats are realised and how to protect against them.

Static Code Analysis

This is the use of a code analysis tool the performs automated scanning of the code and / or binaries for potential security weaknesses.  Good tools also provide remediation guidance for the discovered issues and a workflow for assigning the issues and documenting how it will be remediated or mitigated if your don’t already have a tool for this.

These tools will integrate with various development environments and source repositories, along with different development processes.  If you are not already using one I would recommend performing an analysis of the key players in the market to assess the best fit for your environment.

Peer code review

This is the process of ensuring different developers assess each others work.  This should include cross team assessments with a strong focus on code quality and maintainability as well as security.

Encouraging this process to be as open as possible, to enable open debate about the best way to code will definitely be beneficial.

While code quality may not be strictly a security concern in the traditional sense, the better written, commented and maintainable code is, the easier it will be to maintain the applications security over the longer term.  This is especially true as it is developed and worked on by multiple people and teams.

Dynamic Application Analysis / Web Application Scanning

Similar to the static scanning, this will be an automated process, carried out using a scanning tool.  This is the process of assessing a running application for security vulnerabilities.  These usually focus on areas of user interaction such as web pages so will not be suitable for all systems.

The need for a running system means these scans fit later in the process than the static scans, and usually fit well through the testing phase of any project / development work.

It should be noted that while these are more effort than static scanning, they should be considered especially for larger or more critical systems as they will find issues earlier and at a lower cost than pen testing, thus ensuring less issues are found later in the process.

Penetration Testing

This is the process of dedicated professionals, usually from a specialist third party attempting to ‘hack’ the solution.  This is usually the final check from a security perspective that a piece of development or an application is secure enough to go live.

Due to the costs and efforts involved it is likely that you will want to haver a clear process in place for when and how often pen tests are required.  Depending on your industry there may also be minimum regulatory requirements around how often systems are pen tested.

Associated processes

I have included this as a catch all to highlight that all of the above processes need to have agreed and working feed back loops to ensure the items they identify are assessed and remediation agreed.

Risk Assessment and Ownership process

Following the above point, and discovered vulnerabilities that cannot be fixed or mitigated will lead to a risk to the organisation.  This must be formally assessed in terms of the level of risk, and then accepted for an agreed period by an appropriately senior business owner.  The risk process is an entire topic of it’s own!

Developer Training

I was not sure whether to put this at the start or end of the list as it must be an ongoing process outside of any specific project or development work.  As well as ensuring that your developers have approbate levels of secure coding training, this should be seen as a key part of your engagement with the developers and getting their buy-in for secure development.

Depending upon the size of your organisation I would recommend a combination of on line computer based training (with a programme to increase the skill / knowledge on the courses over time and dependant on the experience of the developers), workshops and presentations from external companies, including pen testers.  For larger organisations secure development forums and ‘conferences’ could also be considered.

 

While nothing is completely secure, especially as complexity increases, if you follow these steps as part of the process you will end up with applications that are definitely not the ‘low hanging fruit’.  This will reduce your risk of any application related breach.  In addition it will mean that should you have a breach your organisation will honestly be able to say that they had done what they could to ensure secure applications, and the protection of the data you hold.

As final thoughts for today’s post, do not take these in isolation, this only covers the application part of your security, all the other key areas from network security to JML (Joiners, Movers, Leavers) processes must be in place to ensure an appropriately secure organisation.

K

 

 

 

Gartner Security and Risk Management conference – Continuous Application Security Monitoring

This was a talk from Whitehat Security covering the the increasing need for continuous application security monitoring and how this should be integrated with the SDLC;

– Attacks becoming targeted to specific companies / industries

– Risk of severe brand damage

– Security risks becoming key concern at board level

 Effective web application security programs must comprise of;

  • Continuous, concurrent assessments
    • Continuous process – restart on completion of assessment, automatic, no need for manual intervention
    • Assess multiple applications / code bases concurrently, not serially – minimises vulnerability window
  • Manage Security posture
    • ongoing metrics and measurement
    • Real-time risk modelling
      • Understand exposure to high value business applications
      • Accurate prioritsation
      • Analytics and trend reporting
      • Benchmark with industry peers
      • Dashboards and in-depth vulnerability reports
  • Implement across SDLC
    • From requirements and design through development to deployment and production monitoring
      •  Production assessments (immediate response)
      • Pre-production (reduce cost)
      • Source code analysis (faster remediation)

Talk was very brief and don’t go into any real detail about what you should do, when to do it, how the SDLC might actually look, process of find issues – verify – plan – resolve – test not covered.  Basic points that were covered do make sense though but I’d have liked the full session to be used and a lot more detail to be covered.

Completely agree however that continuos monitoring of application and code security should be high on the security agenda – remember, that vast majority of vulnerabilities and successful attacks are against applications..  Secure development should be a key foundation of any businesses SDLC.

K

RSA Conference Europe 2012 – Developing Secure Software in the age of Advanced Persistent Threats

Talk presented by Dave Martin and Eric Blaze, both security officers from EMC.

March 2011 – RSA suffered a breach from an Advanced Persistent Threat (APT) type attack.  This was big news and many customers we affect, having to replace their RSA tokens etc.

Security groups in high tech organisation, with EMC being the example – Product security group and IT security organisation.  Where;

–          Product security is focussed on the security of the products produced by the business, deploying patches to customers etc.  This can be looked at as the products impact on the customer’s risk.  They at EMC work on the premise that the customer’s network where the product will be deployed has been compromised so security is paramount.  Secure development / code and application focussed.

–          IT security organisation is responsible for the security of the IT enterprise itself.  This can be looked at as the security impact on enterprise risk.  Generally tend to be much more infrastructure and system focussed.

The environment is changing – environments much more likely to be compromised in a subtle, planned, long term manner (APT) rather than the traditionally more blunt and opportunistic attacks / compromises.

What are the characteristics of these changes?

–          Single minded, determined and innovative

–          Targeting individuals over systems

–          Through reconnaissance will understand your processes, people & systems better than us

–          Will exploit ANY weakness

–          Countermeasures increase sophistication

–          Custom malware, NOT detectable by signatures

–          Are not in a hurry will take as long as it take

–          Goal is long term & persistent access

–          The perimeter has shifted, all systems now exist in a hostile environment

What are the implications of this?

Real attacks that have been publically reported have included;

–          Loss of intellectual property

–          Loss of cryptographic secrets

–          Loss of source code

–          Attacks against cloud services

Mandiant M-Trends 2012 reports that 94% of companies find out they have been compromised from law enforcement, and the median length of time from when a company is compromised to when the breach is discovered is 416 days!  Do you know your network is secure, can you report with confidence to your board and shareholders that you have adequate, intelligent monitoring and solid layered defence in depth in place?  Is your organisation aware of the risks at all levels?

We must assume that we are compromised! – the Security for Business Innovation Council in August 2011 stated;

“Consider that no organization is impenetrable. Assume that your organization might already be compromised and go from there.”

Technology providers must support this by adopting their product security strategy in the following ways;

–          Create an integrated governance model

–          Build intelligent monitoring into products

–          Design layered defence into products

How do they do this?  Product security and Organisational security must work more closely together to expand the SDL (Secure Development lifecycle) and collaborate on standards such as;

–          Source code management

–          Anti-counterfeiting

–          Cloud / Hosting

–          Supplier risk management

–          Software integrity controls

–          Make product strategy part of the enterprise risk strategy

–          ..

Make logging of events more intelligent; Build attack-aware software.

–          Leverage threat modelling within the software to log abuse such as Buffer Overflows and SQL Injections

–          Evolve from logging to debug code issues towards logging that is much more useful for detection for example by including anomaly and behaviour logging in program logic

–          Design software to integrate with and leverage the existing enterprise risk ecosystem – white lists, reputation awareness etc.

Incorporating layered defence into applications / services to resist APT type attacks can be done in various ways including;

–          Utilising split-value cryptographic authentication.  This is where Passwords are split and stored across two servers with one hosting part as an XOR’d random number and the other as a random number.  Thus the attacker has to compromise two servers and crack both parts within a small time window as a new random number regularly refreshed.

–          Assume source code is compromised – anything can be eventually reverse engineered;

  • Never hard code secrets,
  • Adopt a Secure Development Lifecycle,
  • Threat model for source code exposure,
  • Build integrity control into source code reviews
  • Pay attention to comments – we should comment for best practice and code support, but make sure things like ‘To do, must add security here’ are mot left in the code!

–          If you use agile methodologies, ensure you have a security based story.  Review the recommendations from SAFECode;

In summary we need to develop using secure methodologies and use the assumption that all systems are or will be compromised.

K