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

Application Security is more than development security

Last week I wrote about the OWASP top 10, and the main steps that I think make up an application / development security programme.  This can be found here; http://www.kevinfielder.co.uk/security/why-does-the-owasp-top-10-never-change/

Following from this I want to discuss the security of your applications is actually so much more than the secure development and assurance lifecycle along with developer training.

Doing all of the things I previously mentioned, tailored for your environment, will ensure you have as secure an application as is reasonable possible when compared to your threat landscape and risk tolerance.  However the actual application / code is only part of the security story.

So what next? Does that mean your application is secure?  Does it mean it is secure in all environments?

I am a strong believer in the principle of defence in depth.  Even if you believe your application to be completely secure under any circumstances, I would always recommend having multiple layers of defence.  Some of these layers will be independent security tolling, and some will be within the application itself e.g. security SDKs that can be incorporated invisibly into your application.

The below list will highlight a few of the areas you should consider in order to protect your applications and the data they hold about your business and it’s customers.   The list focusses on technical security measures rather than processes, which are a completely different topic.

Application Firewalling

A ‘normal’ firewall is great for providing very fast and robust IP and port based filtering.  However it has no understanding of what should be sent to the permitted IP addresses and ports.

An application firewall understands the traffic your application should receive.  The most typical application firewall is the WAF (Web Application Firewall), Database firewalls also exist.  Web application firewalls will automatically be able to protect your web applications from known attacks like SQL injection.

A further benefit is that specific rules can be created to protect against specific vulnerabilities that may be discovered by your code analysis tools or pen tests.  This can aid speed to market by protecting your application while a fix is worked on.

The key thing here is that the WAF (or DB firewall etc.) will sit between the users of the system and the application, ‘proxying’ all the connections and alerting on or filtering out malicious traffic before it even gets to the application.

Logging

While this may seem outside of the application, and indeed the SIEM / log monitoring part is, logging the right information is critical.  Unfortunately it is often overlooked.

Do all of your applications log enough information about enough events to provide real security value?  This means a lot more than just things like logon / logoff.  Any ‘security’ interesting activity such as administrative activity, user creation, permissions changes should be logged.  Also consider user activity, so that there is a clear audit trail for whom undertook which actions.

Just as importantly is this in a format that can be ingested and analysed by your security log monitoring systems?  Ideally if you have multiple applications your organisation develops you should have a standard logging format, this would be facilitated by creating / using a common logging API for all applications.

As a final thought on logging don’t forget that for the security team to be able to provide useful alerting from the logs, they need to understand what good and bad look like to your applications.

Server Application control

While perhaps not strictly ‘application’ security, a key protection that rarely seems to be implemented is strong application white listing and application controls.   I mention these as I think they make a key part of the overall protection and I had omitted to cover them in detail previously.  Servers should have a pretty static application lists so the overhead of running whitelisting controls should not be excessive once in place.  The other benefit of these solutions is they also understand how many applications should work, so they can prevent even compromised commercial applications from misbehaving.  This should be seen as a key protection for any high risk application servers in your environment, especially those hosting internet facing applications.

Mobile application and device protection / analysis

This is one of my current areas of interest.  How do we protect mobile applications that will be installed on fundamentally untrusted devices?  This can apply so normal Windows / Mac apps as well – see below.

So your application is ‘secure’.. Some questions to get you thinking about the environment a mobile application will run in;

  • How secure is it if the mobile device is compromised and there is key logging software on the device, or man in the middle software that changes the users inputs before sending them to the server etc?
  • How do your servers know if the application talking to them is your application or an exact copy of your application that has malware added?
  • How does your application stay up to date to detect the latest rooting / jailbreak methods and malware?
  • Does the behaviour within the application look like a human user, a bot, someone remote controlling it?

It is to enable us to answer these questions, and more, where mobile application security solutions come into play.  I’ll not cover these in detail as there will be an upcoming post very shortly to cover this specific point in more detail.  Suffice to say if you run mobile apps that handle any sensitive data or transactions etc. this an area you need to be all over.  This also has multiple wider benefits highlighted further down this post.

Remote host security (if you supply an application to them)

This is a similar idea to the mobile security one.  With the continuing malware epidemic across Windows, and the increasing prevalence of malware on Mac and Linux protecting your applications on remote machines should be investigated.  Again, this is especially relevant if you supply an application that processes sensitive data of any sort.

On one hand you could argue that the security of the end point is your customers responsibility, and you would be correct.  However given the challenges faced by most people, especially in the personal or SME markets is this a realistic stance to take?

Given the ease with which you can integrate a host protection SDK from one of the many vendors out there, I would certainly recommend looking into this option, especially if you charge your customers for the service.

Remote browser security

This is where we look at options for securing, or at least monitoring the remote browsers that connect to your web applications whether from mobile or more traditional desktop devices.  This is the area where we have least control, as we are not installing anything on the remote device.

However all is not lost, we can insert various security measures into the page to look for potential browser issues, ID the browser and machine, and perform cool things like in field encryption.

As with the mobile security solution I would recommend that you investigate commercial options here as they will keep themselves up to date against evolving threats and also provide a wide range of added functionality like risk scoring, automated blocking etc.

Also as with the mobile security I’ll write about this in more detail, as in my experience this is overlooked by the vast majority of organisations.

Authentication

This one shouldn’t need any introduction.  In this case what I am referring to is the confirming to an appropriate level that a users is who they attest to be.  There are however many pitfalls around authenticating users of a system.  Obviously ensuring someone is who they say they are is key to securing your applications and their users.

The added benefits of supporting better authentication than passwords are much broader than just being more secure.  You can offer a much better journey for your users, with reduced or no friction for many activities.  You can also gain a lot of useful data as many authentication solutions collect extensive data around the user and device to enable risk based authentication.

Don’t forget, how you do authentication is also incredibly visible to your users and one of the first ways they interact with you every time you use the application.  So this is a great opportunity to both provide a great impression and to highlight that you take security seriously right from the ‘front door’.

Authentication is another area I will be covering in more detail as it is critical we move away from passwords.

Further Benefits

Consider the multiple wider benefits of remote security solutions and authentication;

  • More secure customers = better security for you.
  • Offering security = differentiation and potentially something you can charge for.
  • Data Data Data – the more data you have about your customers and their behaviours, the more interesting analytics you can perform.

These benefits all apply to mobile application security solutions, remote host security, remote browser security and to some extent new authentication solutions.  I briefly explored some of these in my earlier ‘Extending the Perimeter’ article, and will expand further on these in following posts.

Conclusion

Don’t forget that this is all in addition to all the ‘standard’ security stuff you must be doing anyway such as Firewalls, IDS/IPS, anti malware / host security, standard hardened builds, vulnerability scanning and patching etc.

If you have been following my last few posts, you should have a good idea of the basics required for general and application security, plus a few more advanced thoughts from this post.  Once you have these security basics in place,  you can then start looking at the even more interesting stuff!  This includes network and application behavioural monitoring and big data analytics.

As always, do the ‘basics brilliantly’ before spending too much time on more advanced security.  Malicious individuals and groups will tend to go for the low hanging fruit.  Even if they are specifically targeting you, they will look for the easiest way in.  No amount of advanced, behavioural monitoring will protect you if you’re hosting unpatched servers on the internet with single factor authentication and simple passwords!

More next week!

K

Web Application Firewalls

This talk from Gartner covered WAFs, their functionality, if they are required and possible alternatives;

Software security is improving but hasn’t caught up with the threat landscape.

Attackers have Motivation, Times, Expertise and many targets.

Software security can be improved by better education, QA, SDLC, Frameworks and tools.

  • This helps close the gap, but it still remains
  • Many legacy applications or components will exist for a long time

 Defence in depth approach is required to protect applications;

  • Firewall – allows or blocks traffic based on IP and port – positive security model; Deny all traffic unless explicitly allowed
  • NIPS (Network based Intrusion Prevention System) – Negative security model: Signatures and protocol validation
  • WAF – Identifies and blocks application layer attacks
    • Negative security model – Fixed rules, Blacklist known bad, expert deployment
    • Positive security model – Automatic application behaviour learning, whitelist known good, stratighf forward deployment model
    • Passively block or actively modify traffic to prevent specific attacks

Additional functionality over other network security tools found in many WAFs;

  • Authentication and authorisation
  • ADC functionality
  • SSL termination
  • Anti-scraping
  • Threat intelligence
  • Content inspection, data masking, and DLP

 Differentiators;

  • All have basic signatures and filtering
  • Differ in;
    • Level of granularity
      • policies per application
      • policies per url
      • fully scriptable rule engine vs. high level settings
    • Positive model capabilities
    • Additional functionality
    • Deployment methods

Interest in WAF from a business risk perspective is increasing: 

  • Protects against identified vulnerabilities: Buys time as a quick fix, and provides long-term mitigation for legacy Web applications.
  • Protects against generic classes of attacks, such as SQL injection and brute force.
  • Protects against attacks targeted at your application: Requires active response and granular policy settings.

Also, do not underestimate the benefits of the extras such as performance, caching, authentication..

What are the latest developments in WAF technology?

  • Evolution in data interchange and protocol standard support, such as JSON, XML, GWT, HTML5, SPDY, IPv6
  • User and device validation and integration with Web fraud prevention:
    • True source/real IP identification proxies
    • Geolocation and reputation services
    • Injection/Execution of code for user validation and rudimentary fraud detection
  • Increasing support for Web vulnerability scanners (DAST): “Virtual patching”
  • Support for virtualisation and SaaS Web applications, and cloud delivery options for WAF
  • Improved layer 7 DDoS protection

WAFs, are they viable for the future?

Yes..

  • They provide application layer functionality largely unavailable in many other network based defences.  They should be considered as part of your defence in depth profile for any web applications.
  • Cloud based solutions may become more viable
  • Detection quality will improve as they better understand your applications and also the browsers capabilities
  • Detection engine improvements will be required in order to keep up with evolving threats
    • But must not impact performance!
  • Must scale with the web applications.
    • Virtualisation support is critical

What alternatives are there?

  • Secure coding the the main alternative.  This sounds imple, however…
    • History shows that this fails
      • Bad scalability
      • Much insecure legacy code
      • No control over code – software from vendors, third party code etc.
    • Some functionality may be subsumed into other technology such as ADC (Application Delivery Controller) and CDN (Content Delivery Network) – so watch these spaces.
    • NGFW (Next Generation Firewall) and NGIPS (Next Generation Intrusion Prevention System) are becoming more application aware, but do not and are unlikely to ever deliver full WAF functionality

Recommendations;

  • Determine use case;
    • Compliance – buy “anything”…
    • Security – Buy a leader with low false positives and simple management
    • Application security – buy as part of an application initiative, ensure advanced policies are supported
  • If you have ADCs – asses the capabilities of these
  • Track CDN WAF capabilities
  • Complement with comprehensive monitoring and alerting capabilities

This was a very interesting, vender neutral talk that provides a good intro to WAFs, and some useful thoughts on implementing them and possible future enhancements.  Recommended.

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