Low friction, secure online payments

Online payments whether made from a traditional PC or any mobile device must be secure, strongly resistant to fraud, and convenient.

Currently online payments suffer from a couple of key issues relating to ease of use and security;

·         Extra security features such as 3DS (3D Secure) provide a frustrating consumer experience.  This leads to consumers abandoning shopping carts and merchants disabling the feature where they are provided the option to do so.

·         False rejections of payments by the issuers, again this provides a terrible user experience and shopping cart abandonment.

 

Both of the above issues lead to frustrating situations.  Examples of these are when people forget their 3DS credentials, or when you call your bank to be told the rejection was because of the merchant, then the merchant says it was the bank!

 

In addition to this the upcoming EU rules on electronic payments authentication, how we verify that the person who is paying is the right person, are likely to add to this complexity.

 

These regulations are the Revised Payment Services Directive (PSD2).  They have three objectives: harmonization, innovation and security.

On security, PSD2 requires ‘strong customer authentication’ to be applied for all electronic payments in Europe.  Strong authentication in this case refers to using at least two of these three factors;

·         something you know such as a password,

·         something you have such as a card

·         something you are, for example, a biometric.

 

The EBA (European Banking Authority)  is responsible for the regulatory technical standards to deliver strong customer authentication.

 

The above issues and potentially increasing complexity leads to a poor experience and shopping baskets being abandoned.  This is due to either friction in the process or false rejections of payments by the issuers.

 

So how can this situation be improved upon? We need a solution that meets the needs of consumers, merchants and issuers as well as the intent of the proposed PSD2 regulations?

Breaking these down;

 

Consumers want a safe, seamless and reliable payments ecosystem.

Merchants want a safe, seamless and reliable payments ecosystem that maximises consumer spending and minimises fraud.

Issuers want a safe, seamless and reliable payments ecosystem that maximises consumer spending and minimises fraud.

The EU and EBA want a safe, seamless and reliable payments ecosystem that maximises consumer spending and minimises fraud.  Additionally they specify through PSD2 that we must verify that the payer is the correct person using ‘strong authentication’.

 

As you can see the needs of the majority of people in the payments ecosystem are basically the same, safe, seamless and reliable payments!

 

Can we solve this and provide a solution that will minimise fraud, improve acceptance rates while maintaining or improving the customer experience.  The short answer is YES.

 

By combining advanced authentication solutions with card details it is possible to provide strong assurance that a user and card are correctly linked and that a payment is genuine.

 

Utilising relatively simple code and an authentication solution fast enough to be in the online transaction flow enables us to reliably link a card to a device.  Note when I say device I include laptops / desktops as well as phones and tablets etc.

 

By doing this we can immediately identify multiple attributes about the card, device and behaviour such as;

  •  Have we seen this device and card combination successfully used before?
  • Have we seen the same name on a different card from this device before?
  • Does this behaviour align with previous successful payments from this combination such as volume, velocity, amounts etc?
  • Where were these payments made from?

 

This is in addition to all the traditional fraud analytics applied to the card behaviour alone.

 

3DS can still be incorporated if required, even with all this additional information.  However its use can be minimised by asking questions such as; 

  • Have we seen successful 3DS from this device and card combination within a predefined period? 
  • have we seen the same name on a different card from this device successfully authenticate with 3DS?

If so then trust this as if it was a 3DS payment.  This would enable the ability to provide the assurance of 3DS, while minimising it’s adverse impact.

 

This requires some innovation and for the issuers, schemes and processors to work together, along with the EBA recognising that this meets the intent of their proposed regulations.

What are the next steps?

Schemes and issuers, work with the processors to enable these benefits.  Accept greater assurances and risk based decisions from processors.  A higher payment acceptance rate and lower fraud, all with minimal effort clearly benefits everyone.

To the EU, EBA and those writing PSD2, engage in the discussion and realise there are ways to meet your intent without adversely affecting the payments ecosystem.  Intelligence and innovation can provide ‘strong authentication’ without the need for any extra complexity in the payments process. We can in fact reduce the friction while improving the security.

 

Everyone involved in the payments ecosystem wants pretty much the same things, let’s be innovative and achieve these in ways that improve the experience for merchants and consumers.  This ultimately improves things for everyone!

 

Feel free to contact me via this blog, or find me on LinkedIn to discuss further and if you’d like to know some more details around how this really can work in practice.

K

Gartner Security and Risk Summit; Cool Vendors

 

Hi All,

I know I promised a post on the insider threat and how to best manage the risk.. That is on it’s way, it’s a big topic!

In the mean time I attended the first day of the recent Gartner Security and Risk Management Summit earlier this week.

While not deeply technical or focussed on a specific risk topic, the presentation on their top 10 ‘cool vendors’ was quite interesting.  In a similar way to my recent ‘Innovative End User Technology Security’ post, this one will hopefully give you some new vendors to consider when solving issues for your business.

The Gartner definition of ‘Cool Vendors’ is that they are;

  • Technologies that help security leaders embrace;
    • New approaches to business enablement
    • New approaches to threat prevention
    • New responsibilities for IoT, OT and embedded systems
  • On the left of their own ‘hype cycle’

They must however be real vendors with solutions that are available today, not vapourware or soon to be released.

The recommendation is that action, even if it is just investigation and understanding, is needed today.  This is to help ensure the security of your organisation today and tomorrow.

Things you should be asking when looking at your organisations security architecture and defence in depth / diversity strategy;

What technology areas should information security invest in, to;

  • Protect digital assets from advanced and targeted threats?
  • More rapidly adapt to changing digital business requirements?
  • Support building a next-generation intelligent SOC capability?

Which interesting vendors and solutions should be investigated in order to achieve these goals?

The presentation split the ‘cool vendors’ into 10 categories across 3 groups;

  1. Threat Facing
  2. Enablement and Access Facing
  3. Intelligence-Driven SOC

 

  1. Threat Facing

These are technologies primarily aimed at detecting or preventing malware and attackers.

EDR – Endpoint Detection and Response

New solutions that aim to respond to advanced attacks that evade traditional endpoint protection solutions.  If you know compromise is inevitable and are looking at ways to improve your end point protection companies in this space should be considered.

Example players in this space include;

  • Tanium
  • CounterTack
  • Carbon Black
  • Cisco
  • FireEye
  • Cybereason
  • CrowdStrike
  • RSA
  • Ziften
  • Triumfant
  • Confer
  • Bromium
  • Invincea
  • Symantec
  • Intel
  • Trend Micro

Non Signature Approaches for Endpoint Prevention

Solutions that use technologies such as machine learning, exploit prevention and memory injection prevention.  The aim of these is to supplement or replace traditional signature based / ‘heuristic’ anti malware solutions.  Another possible application is where project to implement timely patching and maintenance of systems have stalled and compensating controls are required.

Example players in this space include;

  • Cylance
  • Palo Alto Networks
  • SentinelOne
  • Morphisec
  • Bromium
  • Deep Instinct
  • Invincea

Remote Browser

These are solutions that separate the browser function from the local desktop.  The premise being that a lot of attacks originate from malicious or compromised sites on the internet.  If you can separate the browser into a secure environment and effectively just send a video and audio stream to the desktop you can prevent these attacks.  This is the category that the Garrison solution I previously wrote about fits into.

Example players in this space include;

  • Spikes Security
  • Menlo Security
  • Light Point Security
  • Authentic8
  • Fireglass

Microsegmentation and Flow Visibility

These solutions can provide visibility can control of east-west traffic flows across the enterprise.  The aim of this is to detect and prevent lateral movement of attackers or malicious users across the network.

Example players in this space include;

  • VMware
  • Cisco
  • Illumio
  • vArmour
  • Trend Micro
  • Catbird
  • CloudPassage
  • GuardiCore

Deception

Technologies designed to device attackers into thinking closely monitored security systems are real business systems hosting data they would want to access.  These have been around for a long time and are often referred to as ‘honeypots’ or ‘honey nets’.  Recently some technologies have become a lot more mature and realistically deployable.  Businesses are also increasingly understanding the need for more advanced security solutions.

Example players in this space include;

  • Attivo Networks
  • TrapX Security
  • Cymmetria
  • GuardiCore
  • illusive networks
  • Javelin Networks

 

2. Enablement and Access Facing

Cloud Access Security Brokers (CASB)

The aim of these solutions is to provide a single point of control for cloud use in the organisation.  These can detect, control and apply various security functions such as access control lists and encryption to cloud use.

Example players in this space include;

  • Skyhigh Networks
  • Netskope
  • CipherCloud
  • Microsoft (Adallom)
  • CloudLock
  • Blue Coat (Elastica, Perspecsys)
  • FireLayers
  • Palerra

User and Entity Behavioural Analytics

No presentation this year would be complete without a mention of behavioural analytics of some sort!

The aim or user and entity behavioural analytics is to analyse and correlate user behaviour across systems and networks for indications or malicious behaviour.  This is in order to detect things like compromised accounts or malicious insiders.

Example players in this space include;

  • Securonix
  • Gurucul
  • Fortscale
  • Splunk
  • Niara
  • Interset
  • E8 Security
  • LightCyber
  • Microsoft
  • Rapid7
  • Exabeam
  • Forcepoint
  • Bay Dynamics
  • BottomlineTechnologies
  • CynetSystems
  • DtexSystems

Pervasive Trust Services

This is a particularly interesting area.  These are trust services that are designed to scale to cover billions of devices, including IoT devices that may have limited processing capability.

This requires a fundamental paradigm shift to the web of trust model with distributed consensus.  We must realise trust is shades of grey, not the traditional yes / no authentication.  If the trust is higher than the risk, proceed.

This is another area I’m likely to write up in more detail as it is an exciting space.  Likely to become a lot more relevant as IoT grows, and also as regulations like PSD2 / GDPR come into play that require more identification and authentication for every payment.

Example players in this space include;

  • Certes Networks
  • CSS
  • ForgeRock
  • ARM Holdings (Sansa Security)
  • Guardtime
  • HyperledgerProject
  • Tyfone

Security Testing for DevOps

Tools and solutions that enable the integration of security testing into the automated DevOps workflow.  This enables secure development and applications, without adversely impacting delivery timelines.

Example players in this space include;

  • Hewlett Packard Enterprise(HPE)
  • IBM
  • Veracode
  • Amazon
  • Contrast Security
  • Synopsys (Quotium)
  • Immunio
  • SecuPi
  • Sonatype
  • Black Duck

3. Intelligence-Driven SOC

These are solutions that aim to provide greater intelligence and orchestration to the SOC (Security Operations Centre) in order that it can scale and spot the key security events.  These tools also enable greater use of threat intelligence feeds to support the SOC.

Example players in this space include;

  • CyberSponse
  • Hexadite
  • I.D. Systems
  • Phantom Cyber
  • Swimlane
  • IBM (Resilient Systems)
  • FireEye (Invotas)

 

I hope this has provided a useful overview of some key areas you should be thinking about in your security strategy.  The companies to look into are a mix or new players and more established companies trying to get into new areas either via development or acquisition – as always interesting times in the security space!

Many of these, especially areas like behaviour analytics and trust are getting a lot of hype, so be prepared for questions from your more security aware board members!

Feel free to ask any questions you have.

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

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