A practical approach
I’ve been featured in an eBook by Thales sharing my thoughts on challenges organisations face on their Zero Trust journey and how to overcome them. It’s a huge topic that can be approached from different angles and it’s certainly difficult to capture it in a single quote. However, asset management should be an important consideration regardless of an implementation model.
I had a privilege to engage with NHS Digital as an external consultant in a technical architect capacity to help enhance their cyber security capabilities. NHS Digital continues to play an important role in the current pandemic in the UK and it was an honour to be able to contribute to the security of their operations.
Microsoft Certified Azure Fundamentals (AZ-900) is an entry-level qualification focusing on core cloud concepts and Azure services. It doesn’t have any prerequisites so it’s a natural first step on your journey of mastering Azure cloud.
If you have experience with cloud technologies from other providers, you might be already familiar with the basics of cloud computing but that doesn’t mean you should skip this certification. GCP, AWS and Azure have their own peculiarities and despite having seemingly similar offerings, there are significant differences in how their services are provisioned and configured.
Studying for this exam will give you a good overview of Azure-specific terminology and services, and will be useful regardless of your previous skill level.
I recommend the following free resources to help with your preparation:
In my previous blogs on the role of the CISO, CISO’s first 100 days and developing security strategy and architecture, I described some of the points a security leader should consider initially while formulating an approach to supporting an organisation. I wanted to build on this and summarise some of the business parameters in a high-level framework that can be used as a guide to learn about the company in order to tailor a security strategy accordingly.
This framework can also be used as a due diligence cheat sheet while deciding on or prioritising potential opportunities – feel free to adapt it to your needs.
I’m often asked what the responsibilities of a CISO or Head of Information Security are. Regardless of the title, the remit of a security leadership role varies from organisation to organisation. At its core, however, they have one thing in common – they enable the businesses to operate securely. Protecting the company brand, managing risk and building customer trust through safeguarding the data they entrusted you with are key.
There are various frameworks out there that can help structure a security programme but it is a job of a security leader to understand the business context and prioritise activities accordingly. I put the below diagram together (inspired by Rafeeq Rehman) to give an idea of some of the key initiatives and responsibilities you could consider. Feel free to adapt and tailor to the needs of your organisation.
You might also find my previous blogs on the first 100 days as a CISO and developing an information security strategy useful.
Zero Trust is a relatively new term for a concept that’s been around for a while. The shift to remote working and wider adoption of cloud services has accelerated the transition away from the traditional well understood and controlled network perimeter.
Security professionals should help organisations balance the productivity of their employees with appropriate security measures to manage cyber security risks arising from the new ways of working.
When people talk about Zero Trust, however, they might refer to new technologies marketed by security vendors. But in my opinion, it is as much (if not more) about the communication and foundational IT controls. Effective implementation of the Zero Trust model depends on close cross departmental collaboration between IT, Security, Risk, HR and Procurement when it comes to access control, joiner-mover-leaver process, managing identities, detecting threats and more.
Device management is the foundation of an effective Zero Trust implementation. Asset inventory in this model is no longer just a compliance requirement but a prerequisite for managing access to corporate applications. Security professionals should work closely with procurement and IT teams to keep this inventory up-to-date. Controlling the lifecycle of the device from procuring and uniquely identifying it through tracking and managing changes, to decommissioning should be closely linked with user identities.
People change roles within the company, new employees join and some leave. Collaborating with HR to establish processes for maintaining the connection between device management and employee identities, roles and associated permissions is key to success.
As an example, check out Google’s implementation of the Zero Trust model in their BeyondCorp initiative.
The Software and Security Engineering course taught at the University of Cambridge is available for free online. It includes video lectures, slide decks, reading materials and more.
Whether you are new to information security or a seasoned professional, this course will help you build solid foundations.
Lecture 9 covering critical systems is my favourite. It bring together previous discussions on psychology, usability and software engineering in the context of safety. It adds to the array of the case studies from Lecture 6, focusing on software failures and what we can learn from them. It also offers a fascinating analysis of the Therac-25 accidents and Boeing 737 Max crashes.
In the past year I had the opportunity to help a tech startup shape its culture and make security a brand differentiator. As the Head of Information Security, I was responsible for driving the resilience, governance and compliance agenda, adjusting to the needs of a dynamic and growing business.
I wrote previously on how to assess your threat landscape and what your priorities should be when you start developing a security programme in a new company.
In this blog, I would like to dig deeper and talk about how you actually develop a security strategy with some illustrative examples. You can then use these to further refine your security architecture.
As always, we would start with a Why. Why is security important for your business? Well, you will need to help your stakeholders understand that security can help build customer trust and become a brand differentiator.
And how can this be achieved? To keep this simple, let’s zoom in on three priorities:
The aim could be to arrive to a state where security underpins all products and services to offer customers a frictionless experience.
Talking to your business stakeholders will help you understand your company’s wider goals and strategy. Let’s imagine for a second that these conversations revealed that your organisation, like many others, ultimately want to grow their revenue. They also identified that the way they are going to grow their revenue is through increasing sales, building customer trust, improving products and services and scaling operations to better meet customers’ needs.
Vulnerable product, misconfigured infrastructure, insecure operations, inadequate compliance regime and inability to withstand incidents all prevent the business from achieving its objectives.
You can now prioritise your security activities to align with these objectives, for example by grouping them into product, infrastructure and people security, as well as wider compliance and resilience objectives.
Remember, the above is just an indicative timeline. The reality will very much depend on your organisation’s priorities, maturity and resource availability.
Modern digital technology underpins the shift that enables businesses to implement new processes, scale quickly and serve customers in a whole new way.
Historically, organisations would invest in their own IT infrastructure to support their business objectives and the IT department’s role would be focused on keeping the ‘lights on’.
To minimise the chance of failure of the equipment, engineers traditionally introduced an element of redundancy in the architecture. That redundancy could manifest itself on many levels. For example, it could be a redundant datacentre, which is kept as a ‘hot’ or ‘warm’ site with a complete set of hardware and software ready to take the workload in case of the failure of a primary datacentre. Components of the datacentre, like power and cooling, can also be redundant to increase the resiliency.
On a lesser scale, within a single datacentre, networking infrastructure elements can be redundant. It is not uncommon to procure two firewalls instead of just one to configure them to balance the load or just to have a second one as a backup. Power and utilities companies still stock up on critical industrial control equipment to be able to quickly react to a failed component.
The majority of effort, however, went into protecting the data storage. Magnetic disks were assembled in RAIDs to reduce the chances of data loss in case of failure and backups were relegated to magnetic tapes to preserve less time-sensitive data and stored in separate physical locations.
Depending on specific business objectives or compliance requirements, organisations had to heavily invest in these architectures. One-off investments were, however, only one side of the story. On-going maintenance, regular tests and periodic upgrades were also required to keep these components operational. Labour, electricity, insurance and other costs were adding to the final bill. Moreover, if a company was operating in a regulated space, for example if they processed payments and cardholder data, then external audits, certification and attestation were also required.
With the advent of cloud computing, companies were able to abstract away a lot of this complexity and let someone else handle the building and operation of datacentres and dealing with compliance issues relating to physical security.
The need for the business resilience, however, did not go away.
Cloud providers can offer options that far exceed (at comparable costs) the traditional infrastructure; but only if configured appropriately.
One example of this is the use of ‘zones’ of availability, where your resources can be deployed across physically separate datacentres. In this scenario, your service can be balanced across these availability zones and can remain running even if one of the zones goes down. If you build your own infrastructure for this, you would have to build one datacentre in each location and you better have a solid business case for that.
It is important to keep this in mind when deciding to move to the cloud from the traditional infrastructure. Simply lifting and shifting your applications to the cloud may not work. These applications are unlikely to have been developed to run in the cloud and take advantage of these additional resiliency options. Therefore, I advise against such migration in favour of re-architecting.
Cloud Service Provider SLAs should also be considered. Compensation might be offered for failure to meet these, but it’s your job to check how this compares to the traditional “5 nines” of availability in a traditional datacentre.
You should also be aware of the many differences between cloud service models.
When procuring a SaaS, for example, your ability to manage resilience is significantly reduced. Instead, you are relying on your provider to keep the service up and running, potentially raising the provider outage concern. Even if you have access to the data itself, your options are limited without a second application on-hand to process that data. Study the historical performance and pick your SaaS provider carefully.
IaaS gives you more options to design an architecture for your application, but with this great freedom comes great responsibility. The provider is responsible for fewer layers of the overall stack when it comes to IaaS, so you must design and maintain a lot of it yourself. When doing so, assume failure rather than thinking of it as a (remote) possibility. Availability Zones are helpful, but not always sufficient. What scenarios require consideration of the use of a separate geographical region? The European Banking Authority recommendations on Exit and Continuity can be an interesting example to look at from a testing and deliverability perspective.
Be mindful of characteristics of SaaS that also affect PaaS from a redundancy perspective. For example, if you’re using a proprietary PaaS then you can’t just lift and shift your data and code.
Above all, when designing for resiliency, take a risk-based approach. Not all your assets have the same criticality – know your RPOs and RTOs. Remember that SaaS can be built on top of AWS or Azure, exposing you to supply chain risks.
Even when assuming the worst, you may not have to keep every single service running should the worst actually happen. For one thing, it’s too expensive – just ask your business stakeholders. The very worst time to be defining your approach to resilience is in the middle of an incident, closely followed by shortly after an incident. As with other elements of security in the cloud, resilience should “shift left” and be addressed as early in the delivery cycle as possible. As the Scout movement is fond of saying – “be prepared”.
Image by Berkeley Lab.
