CYBERRisk Europe conference

I’ve spent a little time at the CYBERRisk Europe conference this week, both as an attendee and as part of a panel discussion.

One of the most interesting things about this conference is it has been formed as part of the OpRisk Europe conference.  This is a conference focussing on Operational Risk.  I think it is great that people are trying to bring these things together as while “Cyber”, however you choose to define it, is a category of risks, these all come back to business / operational risk and impact.

Cyber / information security / <insert latest buzz word name here> risk must be considered as a part of the overall business risk, while the people assessing the risk may be from different teams this still needs to feed into one central, organisation wide process.  Doing this ensure all risks are considered together, clear business owners of any risk can be identified, and those owners along with the wider board have a clear view of their cumulative risk.

I don’t think that many companies are necessarily there yet, but brining your risk processes and recording / reporting under single organisation wide umbrella would definitely be beneficial.

Other highlights from the conference included some great discussions around;

  • The importance of working with your business and the board to understand and define the risk appetite
    • A great way to help with this is to use various scenarios around what is and isn’t acceptable
  • Ensuring Security is seen as a business, not IT issue, despite Cyber being very IT centric
  • Using Cyber exercise and playbooks
  • The fact that Cyber / Security is a ‘wicked problem’ – look this up!
  • How related Cyber and wider risk is, but that Cyber is likely a faster moving space than organisational / operational risk are used to
  • Where the CISO / security organisation should sit in the organisation.  There was not consensus, other than not within IT, especially for regulated industries.  Thoughts included within the CRO or COO office, or even the CEO office
  • The need to think outside the box to find better ways to solve difficult security problems was frequently discussed – think of the Gordian knot.  Are we solving security problems in the right way?
  • Ensuring that the relevant people in the business understand and care about cyber risk is key to getting buy in for the correct mitigation / remediation / acceptance decisions
  • Being realistic about aspiration vs. realism vs. appetite, for cyber risk – but likely applies to many areas!
  • The fact that contain and respond need to be seen as at least as important as prevent and detect
  • The importance of people, culture and awareness as well as tools and processes must not be overlooked
  • How challenging it can be to justify cyber / security spend, even for seemingly obvious things as we are often ‘proving the negative’ – more on this in a following post.

 

This was a relatively small conference, but well focussed, with some good content and discussion, I’d definitely recommend it.

If you have any questions about the above topics, feel free to ask and I will happily expand on them.

Cheers

K

We must not forget the basics!

Short and sweet post today!

While I regularly talk about new security things such as predictive analytics, machine learning and making security a profit centre, we must never forget the basics!

I was recently asked how I would spend a limited security budget, by a vendor after I suggested HSMs were possibly not the best investment vs. other capabilities if your physical environment is secure, but that is definitely another topic!

My response was that regardless of the latest new security trend or capability, getting the basics right has to come first.  I don’t recall where I first heard it, and it’s certainly not original but the mantra;

“Be brilliant at the basics”

This definitely applies to security as much as many other areas.

I’m not going to list what I consider to be the basics here, I have talked about them before, and there are plenty of great sites covering this topic already.  Two places I would recommend looking are;

SANS / CIS critical security controls for a general list of key basic controls you really must have in place;

https://www.sans.org/critical-security-controls

OWASP top 10 for a more application specific list of the basics you need to be getting right in relation to applications, with a focus on web applications, but many of the points can be applied to pretty much any development;

https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

Happy reading, and remember while the latest tool or solution is likely more interesting, without a solid base of the security basics no matter what you do you will likely be breached via a very simple method!  Fix the ‘low hanging fruit’ first, then do more advanced security.

K

Turning Security into a Profit Centre

Security is still seen very much as a cost centre or necessary evil that is a ‘cost of doing business’.  This, along with a historical challenge around gaining traction at board level has driven the slow move of security to being a key part of most businesses.

This is true even in the industries where security is now seen as critical, and where the board has time and an appreciation for it.  In these industries such as financial services, gambling, big pharma and even gaming, getting funding, resourcing and executive support for security programs is less of a challenge.  However even with this support, the view is still one of security being a cost of doing business.

In order to progress further and make security genuinely a key part of the business, we need to move the conversation on again.

Over the last few years CISOs and security teams have worked diligently to understand their business and speak in the language of their business peers.  This has been a key factor in gaining board support for security.

The next step is to move this further, and work out how security can become a key pat of the business offering for your organisation.

This should likely begin in terms of how you differentiate yourself in the market.  Start thinking along the lines of;

  • How is your companies security different or better than others in the market?
  • How do you ensure your customers data is kept secure?
  • What reassurance can you offer your customers?
  • If your business involves medium to longer term partnerships can you become your customers ‘trusted partner’?
  • Do you have an impeccable record e.g. never been breached, never lost customer data etc.?

The aim here is to think about ways you can make your strong security a part of how your organisation sells itself.  Security needs to become a part of ‘who the organisation is’.  By doing this you’ll move security to the ‘next level’ in the business where is isn’t just a boardroom topic because it has to be, but it is a boardroom topic as a key part of what you do.

By making security a key differentiator for your business, you’ll also make security much more part of the conversation across the business as it becomes part of how your organisation sells itself.

 

Now for the really big bet! Can we move security even further, to not just be a differentiator, but to become something you actually sell?

Whether this is possible or not will depend on your industry, company size, customer base etc.  However if it is possible, think of how powerful this could be!

Imagine not only the benefit to the standing of the security team if you are able to actually sell services and solutions to your customers, but also the benefit to the actual security / risk posture of your organisation!

Have a think;

  • Do you hold large volumes of data on your customers, or their customers?  Could this be used to provide valuable security analytics such as fraud or unusual behaviours?  Could it even be used to provide predictive analytics?
  • Do you run enterprise scale services that you could provide at a relatively low incremental cost to your customers such as encryption, tokenisation, authentication,  …?
  • Could you support your customers in achieving compliance with whatever regulatory environment you work in?
  • Is it possible to securely host your customers services in your own DCs?  This has the added benefit on ensuring communications from the customers systems to yours are secure.
  • Can you provide them other capabilities such as monitoring, vulnerability scanning / management, secure coding guidance …
  • Insert your ideas here!

Seriously, if you work in security, and especially if you have a leadership role think about this.  It’s time for a step change to really make security front and centre of your organisation.  Lets stop being one of the ‘costs of doing business’ and become a core part of what our organisation does!

K

Secure Mobile Applications, part 3 – Bringing it all together!

Hopefully it is fairly obvious from the last couple of posts how I think a mobile application can be made ‘secure enough’ to replace hardware security devices and enable many other capabilities from mobiles / tablets etc.  However I thought it may be useful to provide an overview of how the detailed components will work together to provide this capability.

Many organisations such as banks have or are already launching payment applications that enable you to make payments with your phone rather then needing your bank card, and of course there are Apple Pay and Samsung Pay etc.

So it’s clear people are becoming comfortable with mobile devices for some use cases, sometimes purely software, sometimes with hardware components involved such as Knox or TEE (Trusted Execution Environment).  This is likely helped by the rise of ‘contactless’ payments in many parts of the world.

While hardware components and secure operating system components can form part of a secure mobile application solution, they  are by no means a silver bullet.  As you still need some part of the application to run in normal, untrusted space, you still face the same problems as if there were no hardware solution in place.  What is to stop a malicious application attempting to man-in-the-middle the communications between the secure and insecure environment?  Indeed what is to stop a malicious application from just impersonating the secure component to the insecure one?

Hardware based solutions also face challenges around support and different capabilities on different devices.

This is why I have focussed on a software only proposal.

If we get to the point where we can trust and monitor a software only solution, this opens up so many possibilities – as long as you are on a supported O/S version, you can run our secure application(s) on any device, anywhere.

While we have the above mentioned payment applications, there are much wider use cases when we get to the point that we really do trust the mobile application I mentioned some of these in my original post on this topic.

As a recap, these were;

  • Become your payment instrument.  Not like Apple pay that still uses your card in the background, but actually being your card(s).
  • This can also provide a much richer user experience such as alerting the user every time there is a transaction on the ‘card’
  • Take payments in stores without the need for a physical card payment solution.
    • EMV (chip and pin) becomes EMV mobile devices and PIN / other
  • Replace your drivers license / passport / age card etc. as a valid form of ID.
  • Enable secure signing of legal / contractual documents.
  • Combine with technology like RFID and GPS etc. to revolutionise the retail experience.
  • ‘Card not present’ becomes ‘card present’ (the end of ‘Card not present’ fraud!)
  • Secure mobile banking becomes actually secure and fully featured
  • Support (or deny) any disputed transactions by providing more detailed information about the device, location and users involved
  • Become your mobile medical record – no longer do doctors or hospitals have to look up your records (or not find them), you carry a copy with you, that syncs from the central repository when it is updated

I am sure you can think of many others!

So how do the components previously detailed components all come together to proved a secure, monitored environment?

In ‘real time’ there are 5 main components;

  • The mobile app
  • Secure decision point
  • Real time risk engine
  • Authentication
  • Monitoring

 

The mobile application – this comprises all of the security components deployed to the mobile device, along with the actual application capabilities of course!  These components are the key to understanding the security status of the device.  They also providing details of behaviour, from things like location to the users activity, and authentication information.  These components have the responsibility for securing and monitoring the device and user behaviour, plus ensuring this data and telemetry is securely provided to the secure decision point and monitoring services.

The secure decision point is to provide a central (resilient of course!) control point for all application traffic to pass through.  This enables relevant data to be passed to the correct components such as the risk engine and monitoring solution(s).  In addition this provides an added layer of protection for the back end application services.  Any time the application or user behaviour is deemed unacceptable, the connection can be blocked before it even reaches the back end services.

Real time risk engine enables risk based decisions to be made based on the information from the other security components.  The secure decision point, authentication solution and ‘external’ source like threat intel and the big data platform all feed the risk engine.  This can be applied to  many activities including authentication, user behaviours, and transactions.

Authentication does what the name implies – it authenticates the user, and likely to at least some extent device.  The difference between this an ‘traditional’ authentication is that as well as authenticating at logon, and supporting multiple factors and types of authentication, is that it can authenticate constantly in real time.  Every time the application is used, information about the device, location, user behaviour etc. is passed to the authentication solution, enabling authentication decisions to be made for any application activity.  In addition to providing rich risk information for the risk engine this also enables fully authenticated transactions.

Monitoring, refers in this case to security monitoring of the system components and their data.  This provides expert analysis and alerting capabilities to augment the automated processes of the risk engine, authentication solution and security decision point.  This may be internal staff, a dedicated SoC (Security Operations Centre),  or a dedicate mobile security monitoring centre, or a combination of multiple options.

 

As you can see, all these components combine to provide an understood and secure environment on the mobile device, backed up by real time monitoring, risk based decisions and authenticated activities.

These ‘real time’ components are further backed up by external feed from intelligence sources, and by analytics performed in the big data platform.  This enables learning from the behaviour of users and devices in the environment so that the risk based rules and manual alerting can be refined based on previous and current activities and outcomes.

Depending on a combination of the security requirements for your application, and the resources available, you may not need or want to implement every component here.  Overall the detailed environment provides a software only solution that is capable of providing enough security to enable pretty much any activity.  I’d love to hear your thoughts, and any experiences of deploying and proving secure mobile applications!

 

K

Secure Mobile Applications, part 2

My last post covered some of the benefits of getting to a point where a mobile application can be considered ‘secure enough’ to replace dedicated hardware solutions, including the required mind set move from ‘assumed secure hardware’ to ‘constantly monitored and assessed software’.

As part of the post I included the high level security architecture components / building blocks that be part of the secure mobile application ecosystem.  This post will provide some detail about what each component is and cover their features / capabilities.

For ease of reference I’ll repeat the diagram here.  Observant readers will notice one extra box added since my previous post..

Mobile app security concept - New Page (2).jpeg

I’ll start by covering the security components that will be included in the application on the mobile device;

‘Mobile Security Solution’

This forms the core of the security solution on the device.  Most likely implementation would be an SDK that is integrated with the mobile application and ideally has a dedicated security ‘decision point’ in the architecture before the mobile app connects to the back end services.

This component will provide the core security component on the mobile device providing multiple capabilities including;

  • Jailbreak / root detection
  • Malware detection
  • Key management and secure communications
  • Bot / remote control behaviour detection
  • User and device behaviour analytics
  • In field encryption
  • Potentially fraudulent transactions (e.g. amount sent differs from the amount entered in the field)
  • Application and device tamper detection
  • Application checksumming
  • Code obfuscation and tamper detection

These outputs are all used to create a risk profile of the application environment covering device, application and user behaviour.

This component will also have the capability to send the telemetry to a dedicated third party SOC (Security Operations Centre) for direct 24*7 monitoring and alerting.

‘Authentication solution’

The core authentication component of the solution that will enable the use of various authentication methods to log into the app and also ‘step up’ authentication when performing certain in application activities.

It would be expected that the authentication solution would be FIDO compliant (https://fidoalliance.org/) and provide a variety of authentication solutions from photos to positive device use such as shaking it to push notifications through SMS to actual passwords.  Risk based authentication should also be supported.

What do we mean by risk based authentication?  This is where were utilise a variety of behaviour and device attributes to confirm or support the identification of the user.  This can be used to support other authentication, e.g. fingerprint, plus uninfected device, plus location, plus time and behaviour is much stronger than the finger print alone.

Risk based authentication can also help provide an improved user journey.  For example you may decide that when logging into an application or dashboard, if the user only wants to view certain information or perform low risk tasks risk and behaviour based authentication may be all that is required.  e.g. bob in his business logging in from the same, uninfected device, at the same location at the same time, to view that days sales.. might need no further authentication.

This is where ‘step-up’ authentication then comes in.  Should bob then want to perform a more ‘administrative’ task such as changing the account money is paid to, increased authentication would automatically be requested such as biometrics, one time SMS’d pin etc.

It is likely that the capabilities of the authentication solution will have some limited overlap with the security solution, however this will likely be complementary and provide an improved level of protection.  This aligns with the ‘defence in depth’ security stance.

‘White box crypto / Hardware Security Module’

This box provides the capability to use encryption within the mobile device in a more trusted manner.  This is especially important if there are any concerns that there may be malware trying to access the data on the device.

White box cryptography is a software solution that purportedly provides secure cryptography in even should the keys etc. be compromised e.g. it provides secure crypto in insecure environments.

Hardware security module in this instance refers any hardware security solution available on the device such as ‘secure element’ or TEE (trusted execution environment).

‘Secure Data Entry Solution’

Where there is a need for trusted data entry, e.g. a pin, there may be a requirement for a dedicated solution to this that provides extra security and obfuscation for any inputs to the application.

As with the crypto solution this may or may not be required depending on the security requirements, risk profile and how much the security software and monitoring is trusted.

‘Dedicated Mobile Security SOC’

As mentioned earlier, the mobile security component(s) can report directly to a dedicated SOC that will provide an expert layer of monitoring and understanding of the current risk posture of the device and app.

This would provide an added layer of security and expertise, which may be especially relevant in high risk and / or high transaction environments.

‘Reverse proxy / application delivery device’

The premise of this component in the ‘data centre’ (DC, or cloud) is that it provides a dedicated security device that sits in the transaction path.  This provides a dedicated secure ‘choke point’ to make decisions and prevent malicious connections before they reach any of your back end servers / services.

This solution would effectively be a conduit / connector between multiple security components on the mobile device and within the DC, including the real time risk engine and the log monitoring and alerting solution.

The benefit of having this component in place vs. some of the solutions that provide similar capabilities but rely on decisioning within the application back end is that it provides a hardened device to protect the solution.  This also minimises required changes to the back end of the application in order to provide this security capability.

‘Authentication Provider’

This is the back end of the ‘Authentication Solution’ that will provide the policy based authentication capabilities and ensure the appropriate level of authentication is required for any given activity.  Based on the implemented policies of course.

Ideally this should support multiple policies to enable different applications, user groups and behaviours to have different authentication requirements.  This should also be able to support different authentication methods for the same behaviour depending on a combination of device capabilities and risk.

Another key theme for the authentication solution is that you ensure you work with a vendor who is committed to remaining current as new authentication methods become available.  Once your application is integrated with the authentication solution you can then remain current and support what ever authentication methods you deem appropriate with no further application changes.

‘Real Time Risk Engine – Risk Based Transactions’

This block indicates the capability to provide real time risk scoring of activities or transactions as they happen.  As this has to be in real time and potentially support 100s or 1000s of activities per second it is likely that the rules will need to be relatively simple and easy for a machine to check against in real time.

These will however be refined and improved over time via the longer term analysis performed in the big data platform.

The benefit of having real time risk scoring, and blocking of transactions is that you will prevent a lot of potentially bad activity such as fraud before it even gets to your core systems.

The risk engine will be able to combine the current session profile information from the various tools in the environment, along with some understanding of expected user behaviour.

An example of the kind of contextual risk scoring the solution may provide would be;

Alice logs into her device using strong authentication, there are no indicators of compromise on the device or application and she is in her normal place of business.  Some unusually large transactions are sent from Alice’s device, but there are still no indicators of any issues  These can likely be permitted with very low risk.

Alice logs into her device using her password, there is an indicator of some potential malware, but nothing that should impact the application.  Alice and the device are not one of their usual locations.  Some unusually large transactions are sent through.  While not definitely fraudulent these would definitely carry a higher risk score and may want to be blocked or investigated immediately.

The real time risk engine would receive contextual information from the various components in the mobile application security ecosystem, general threat intel about fraudulent behaviour etc. from the external threat feeds, and updated algorithms and intelligence from the big data platform.

There may also be a link to a dedicated fraud system if this is a financial organisation.

‘Big Data Predictive Analytics’

If your organisation has one, this would be the big data analytics solution that is in place.  Data from all the security tools and threat feeds, not just those for the mobile app, should end up here.

This will then use analytics, machine learning, data scientists expertise etc. to learn the environment and understand how well the real time risk engine is working.  This data would then be used to improve and refine the rules to maximise performance and detection while minimising false positives.

Outside of providing analytics and improvements to the mobile platform, there is immense business and competitive advantage that can be gained from analysing and learning from your security tooling if you can get the whole picture into one place.  This is especially true if you have enough data to start making accurate predictions for you and / or your customers!

‘External Threat Intel Services’

These are exactly what they say on the tin, your organisations sources of external threat data.  While the value of these can be questioned, if you have them, especially if you have found a reliable source of accurate, timely and actionable contextual data then they should certainly feed into you risk engine and data analytics.

‘MSS Monitoring Service’

This is your organisations general security monitoring and alerting service.  This will likely comprise a SIEM (Security Information and Event Monitoring) solution or Continuous Monitoring solution of some sort and a team of dedicated security analysts.  I have shown this as an external service as this is usually the best way to deliver this to small and medium organisations, along with many larger organisations that do not have security as a core competency.  This could of course be provided by an in house solution and team if that is in place in your organisation.

This service will provide monitoring and alerting on any potential security issues and either investigate and initiate incident response and remediation directly or work with your security operations team to do so.

 

This post has turned into quite the essay, I’ll stop here as we have briefly covered the various security components within the mobile application ecosystem.  How this all hangs together and provides a cohesive secure environment will be the subject of my next post.

K

 

Secure Mobile Applications

Subtext, can a mobile application be ‘secure enough’ to replace single purpose hardware devices?

An area I have been discussing for some time is whether we can make a mobile application secure enough that it can be trusted to replace physical devices / items.

If we can achieve this, there are many possibilities for your phone / tablet enabling it to;

  • Become your payment instrument.  Not like Apple pay that still uses your card in the background, but actually being your card(s).
    • This can also provide a much richer user experience such as alerting the user every time there is a transaction on the ‘card’
  • Take payments in stores without the need for a physical card payment solution.
    •   EMV (chip and pin) becomes EMV mobile devices and PIN / other
  • Replace your drivers license / passport / age card etc. as a valid form of ID.
  • Enable secure signing of legal / contractual documents.
  • Combine with technology like RFID and GPS etc. to revolutionise the retail experience.
  • ‘Card not present’ becomes ‘card present’
  • Secure mobile banking becomes actually secure and fully featured
  • Support (or deny) any disputed transactions by providing more detailed information about the device, location and users involved
  • Become your mobile medical record – no longer do doctors or hospitals have to look up your records (or not find them), you carry a copy with you, that syncs from the central repository when it is updated

 

The question is can we?

My take on this is yes.  But with some caveats around how, and what we need to do to ensure the safety of the data used by the application.

The great news for me is that other people are finally starting to get on board with this idea, after a mere 18 months or so it seemed like an opportune time to write in some more detail about my thoughts!

Before we start this discussion we need to adjust the mind-set from

  • thinking about a supposedly secure device that we do little to monitor

to

  • thinking in terms of real time application and behaviour monitoring to provide assurance of the application and device security, along with the user identity and behaviour.

 

For me the ‘assumed secure hardware’ stance seems terrifically old fashioned when compared to a solution where we can monitor and understand the risk profile continuously

Now we are thinking in these more current terms, just how do we go about making a mobile application as secure as a dedicated hardware device?  Indeed, when you consider the more intelligent monitoring and risk assessments we can perform in real time I would position this software solution as considerably better than the existing hardware options.

 

For me the ecosystem for a secure mobile application would comprise of the following components;

Mobile app security concept - New Page (1).jpeg

To avoid this becoming a mammoth post, I’ll cover some of the key capabilities of this system here, and provide details of each component in part 2 of this

Some of the key capabilities these components will provide include;

  • Real time monitoring
    • Data sent to and from app in real time
    • Automated blocking and alerting
    • 24*7 ‘eyes on glass’ monitoring
  • Behavioural monitoring
    • Device
    • User
    • Application
  • Application monitoring
    • Is it the correct application (e.g. checksum)
    • Is it behaving as expected
    • ‘trap’ code in the application that is only accessed of changed if there is an issue
  • Rooting / Jailbreak detection
    • Auto updates to detect new methods or ways of hiding
    • Can alert monitoring and user if detected
  • Malware detection / device interrogation
    • Device ID, software versions etc.
    • Automatically updating detection capabilities
  • User alerting
    • Alerts user if there are any issues detected
    • Alerts user of activity on their account
  • Behaviour blocking
    • Can block some or all in app activity based on the current risk profile
  • Secure communications
    • between app / mobile device and back end
    • frequently changed keys
    • key management and distribution
  • Encryption
    • White box
    • hardware
    • In field
    • In app
  • Bot vs. real user detection
    • detects bot like behaviour
    • detects remote control behaviour
    • build picture of user normal behaviour
  • Real time risk scoring of activity / transactions
    • collection of multiple data points
    • real time risk scoring, decisioning and blocking of transactions and behaviours
  • Multiple authentication methods and step up authentication
    • Policy based
    • Risk based
    • FIDO compatible
  • GEO location
    • Current location
    • Historical locations linked with behaviours
  • Fraud detection
    • Components can detect potentially fraudulent activities such as the amount entered into a field, not matching the amount sent to the back end
  • Trending and predictive analytics
    • Big data platform can provide analytics capabilities and long term trending
    • Machine learning and predictive analytics can guide security enhancements
    • May also become a saleable service for your business

This is by no means an exhaustive list, my intention is to get people thinking about the possibilities for secure mobile applications.  Hopefully this post has got you thinking about how we can secure and monitor our applications on any device, anywhere.  This really will open up a whole new world of possible capabilities for mobile devices especially in the worlds of business and consumers / businesses transacting.

Part 2 will follow in the next few days providing some more details around the building blocks in this ecosystem.

K

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