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

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