Passed my AWS Certified Solutions Architect exam – here’s how you can too

 

Solutions badge

I’ve recently passed my AWS Certified Solutions Architect – Associate exam. In this blog I would like to share some preparation tips that would help you ace it.

  1. Practice

Not only practice makes perfect, some hands-on experience is also a prerequisite for the exam. So there is really no way around that! But what if you didn’t have a chance to use your skills on a real-world project yet? No problem! AWS gives you a opportunity to learn how their cloud components work through AWS Free Tier.  For one year, you can use Amazon EC2 Amazon S3Amazon RDSAWS IoT and many more free of charge,

You want more guidance? Qwiklabs developed a set of labs that specifically designed to help you prepare for this exam. For a small price, you can complete exercises without  even requiring an AWS account or signing up for Free Tier.

  1. Read

I recommend studying AWS Whitepapers to broaden your technical understanding. If you are short on time, focus on these:

  1. Watch

AWS developed a free self-paced Cloud Practitioner Essential course, to help you develop an overall understanding of the AWS Cloud. You will learn basic cloud concepts and AWS services, security, architecture, pricing, and support.

There is also a YouTube channel with free introductory videos and other noteworthy material.

Exam sample questions can help you check your knowledge and highlight areas requiring more study.

Remember, the best preparation for the exam is practical experience: AWS recommend 1+  years of hands-on experience with their technologies.

When you’re ready, go ahead and schedule an exam here.

Good luck!

IoT Security Foundation

IoT

It’s the second year I’m attending the IoT Security Foundation conference and it continues to be a great event.

Strategic and technical tracks run in parallel with vendor showcases and means that there’s something interesting for everyone.

It’s great to see industry practitioners and academics coming together to discuss the ethics of IoT, challenges with design and development and the direction of travel of security.

Some of recorded talks are available on the IoTSF website.

Best practice guidance on vulnerability disclosure, connected consumer products and security compliance framework are available to download.

Helping clients in Saudi Arabia

 

I’ve recently completed an assignment for one of the largest companies in Saudi Arabia where I had the pleasure of helping my clients improve their cyber security posture. During my time there I had the opportunity to explore this beautiful country, learn about its rich history and make a few friends.

And in case you are wondering how an Arabic keyboard looks like, here you go:

jvGavCsCSG6MP5VGAobf6g_thumb_3cf0

Security in mergers and acquisitions: integration

M&A 2

This blog is the second part of the discussion of security in mergers and acquisitions (M&A). I suggest to read Part 1 first, as I’m going to build on it and talk about what happens after the deal is finally signed.

Ok, it’s time to put that champagne glass down. I have bad news: closing the deal was the easy part. Now the hard work begins.

The purpose of the integration phase is to create value. More bad news: 83% of the M&A deals did not boost the shareholder value (according to KPMG global research report) and total average returns on M&A are negative (A.T. Kearney research).

All too often the root cause of these failures lies in poor integration.

There are ample opportunities to start losing the value right at the start during the handover between the deal and integration teams.

To alleviate this, I suggest identifying key resources and preparing implementation plans early in the process. Just like having an overall acquisition strategy and plan precedes the negotiation and due diligence phases, having an approach to integration is key to success. Deliverables, due dates, milestones, information flows are all need to be defined in advance. And cyber security plays a big role here.

A newly acquired company is a prime target for cyber criminals due to the magnitude of change it’s going through during the M&A process. Lack of governance, employee turnover, security vulnerabilities and many other factors can contribute to embarrassing security breaches that affect the reputation of the combined entity.

Key cyber security risks to consider:

  • Regulatory compliance liabilities and impact (e.g. GDPR fines)
  • Theft of intellectual property (data leaks, key employees leave with all the secrets, etc.)
  • Reputational damage (unwanted media attention due to data leaks)

The focus of cyber security post-deal is on protecting the value from internal and external threats, enabling secure integration, achieving long-term security and minimising cultural impact.

This can be attained in the following ways:

  • Supporting the project team deployment (security education, secured laptops, secure remote connection, encryption, etc.)
  • Identifying and prioritising key assets, systems, people and processes
  • Assessing the security of these assets (a carefully scoped pentest might be a good idea)
  • Ensuring confidentiality, integrity and availability of these assets (backups, antivirus, firewalls, patches, etc.)
  • Establishing and controlling access
  • Supporting the rationalisation of normalisation of processes
  • Developing an approach to cyber risk management (including third-party risk)
  • Rolling out security training
  • Supporting secure migration of applications and data
  • Supporting with incident management
  • Supporting with achieving compliance with relevant laws and regulations
  • Setting up a security monitoring capability of the merged entity
  • Establishing governance
  • Developing integrated security strategy and roadmap

Different cultures, attitudes to security and varying control frameworks are among many challenges to consider. Controls are typically relaxed to allow for the integration to go faster. This is where you need to be on a look out for increased threat levels.

To address these effectively, it’s a good idea to split your efforts in two stages: interim and long-term integration.

From the cyber security perspective, during the interim phase, the aim is to assess cyber maturity across the acquired entity rather than come up with a permanent solution.

High-risk areas should be addressed first by establishing interim controls. Long-term integration efforts should be initiated in parallel, starting with development of a security strategy, governance and roadmap.

Proportionality and risk-based approach is key here when integrating the acquired company into your governance structure and control framework. Focus on what matters most and prioritise security controls to protect the value and avoid backlash.

Don’t forget that people would need to still be able to carry out their duties with minimal disruption, but it’s a good idea to establish who needs access to what and why.

Some things can be outside of your control, like losing key employees after deal completion due to inadequate incentive structure. While it might not be your job to design the right retention mechanisms, it’s your responsibility to protect intellectual property, as mentioned above.

Above all, cyber security efforts during the integration process should be joined up with other functions and stakeholder groups. Work closely with the Legal team to minimise potential impact of compliance-related risks, engage Procurement for third-party risk management and align with the executive team to establish the right security culture.

Security in mergers and acquisitions: conducting due diligence

M&A 1

Recently I’ve had an opportunity to support a number of high-profile mergers and acquisitions (M&A) from the cyber security perspective. Although, due to the confidentiality of these projects I won’t be able to share any details, I would like to talk about some learnings and common approaches that might be useful.

The focus of this blog will be on the due diligence process and the role of security in it. It’s written from the buyer’s perspective, but insight into this thought process can be useful if you’re selling too.

Acquiring firms usually seek to fill the gaps in their capabilities (e.g. new technologies) in line with their strategy or to find overlaps allowing for cost reductions through greater consolidation.

Due diligence during M&A is rarely simple, quick or 100% accurate. It aims to reduce risk for both parties involved in the transaction and identify value creation opportunities. Although it might feel brief due to the business pressures, no amount of time will allow you to detect all the threats and identify every risk facing the business.

The main questions you would like to have clarity on from the security perspective are: “What security measures does the company have in place?” and “Are these the right measures?”

Sometimes, it feels like an art rather than a science.  But there are ways to reduce the uncertainty surrounding this process.

Jason Weinstein, former Deputy Assistant Attorney General, U.S. Department of Justice, once said: “When you buy a company, you’re buying their data, and you could be buying their data-security problems.”

Security teams, however, are not always welcome during M&A activities. Why? For one thing, it takes time and costs money to involve them. They may also scare or annoy employees of the target company and can be perceived as slowing things down or, worse still, hampering the deal.

So even when security gets involved, it’s usually quite late in the process with a few days left before the deal needs to be finalised.

To make matters worse, access to the target company is often restricted and the best you can get is a (partially) filled questionnaire. Your security-related questions form a part a broader pre-deal survey, so it’s a good idea to put some thinking what you should ask and why.

A number of subject matter experts in the deal team are all scrambling for limited available time and priority is sometimes given to understanding financials, legal aspects or broader IT strategy, rather than security specifically. Cyber risks, however, should form a core part of the process.

To alleviate some of the challenges outlined above, it helps if the value of the security involvement is clearly articulated (yes, it’s your job to do that). In short, it brings additional expertise to the table, protects the negotiating position and informs senior executives about potential risks, providing recommendations on mitigating them.

To save time, I’ve developed a high-level assessment template that covers all the possible areas of interest from the cyber security perspective and helps identify key assets, systems, processes and employees, but I would never send it as is. You need to do your homework and learn as much about the company and its culture as you can using the information in the public domain.

There are paid-for services out there but Google often does the job, as many OSINT experts would argue. Assuming, of course, you know how to use it! Open source intelligence and research skills at this stage are more useful than ever. Checking the dark web to see if target’s confidential information is being sold by cybercriminals can be useful too.

After the initial research, you can now tailor the questionnaire to verify your initial thoughts. Don’t be shy to ask for evidence if you want to see their policies or latest pentest reports: there are usually secure data rooms set up to share these kinds of documents.

The aim here is to understand the target company risk profile and make the deal team aware of the potential risks and opportunities. You can go one step further and quantify the risk, as this would help inform the value of the deal, potentially reducing the asking price to account for remediation activities during the post-deal phases. Despite the number of unknowns (believe me, it’s normal) it is also a good practice to provide recommendations.

It’s helpful to group your recommendations into three broad categories:

  1.  Risks that should be addressed before the deal can be signed (red flags)
  2.  Items that should be included in the contract (conditions on signing the deal)
  3. Post-deal activities as part of a 30-60-90 day plan that helps prioritise risks mitigation actions

Ask the target to disclose any known security flaws, issues and incidents. It’s probably also a good idea to reserve some funds for the remediation activities post deal. It shouldn’t be all negative; identify value creating opportunities too, if you can.

If you’re a seller, you can increase your marketability by assessing your own assets, discovering your own vulnerabilities and addressing these. Establishing processes to demonstrate compliance is a bonus. But don’t just focus on the current state, think about how your assets are going to stay so post-deal.

Congratulations! You successfully supported the business in making the right decision about this company. But the role of cyber security doesn’t end here. If the board decides to go ahead and the agreement is reached, we are moving into the post-deal stage.

Now, we need to ensure a smooth and secure integration.

GDPR compliance automation: responding to data subject requests

What is GDPR?

The General Data Protection Regulation (GDPR) is a new European legislation intended to strengthen personal data protection for European citizens and harmonise personal data protection rules within the European Union. GDPR replaces the 1998 EU Data Protection Directive and the national laws that implemented this Directive. GDPR becomes the law in all EU Member States without the need for further legislation, though in some areas, Member States are allowed to adopt further specific laws on certain topics, for example, in relation to biometric data and employment data.

What is personal data?

Personal data is defined as any information relating to an identified or identifiable living individual. For example, your name, date of birth, home address, personal email address, your tax identification number, fingerprints, phone number, performance data and medical information are all personal data, but it can also be any combination of data that can identify you.

What rights do individuals have?

The GDPR provides the following rights for individuals:

  • The right to be informed
  • The right of access
  • The right to rectification
  • The right to erasure
  • The right to restrict processing
  • The right to data portability
  • The right to object
  • Rights in relation to automated decision making and profiling.

You can find out more on the ICO website. Companies receive the majority of requests in relation to the right to access and right to be forgotten.

What is the Right of Access?

A data subject access request is when an individual requests to have access to their personal data stored by the company. The purpose of the right to access personal data is to enable individuals to be in control of their own personal data (e.g. understand what personal data is processed and verify the lawfulness of processing).

All personal data which is being processed will need to be provided to the data subject, with a few exceptions to protect the data rights of other individuals and commercial secrets. In some cases, where the relevant systems provide for this, the right of access can be complied with by self-service by the data subject.

What is the Right to be Forgotten?

A data subject may make a request for the right to erasure, also known as the right to be forgotten. The right to be forgotten applies when: the individual has withdrawn consent, the data was processed unlawfully, or the data must be erased to comply with legal obligation. Only data items are forgotten for which the company does not have a legal basis (e.g. tax, accounting, employment, legal, etc.) or business purpose to retain.

The extent to which data can be erased depends on the nature of the personal data. For example, an employee cannot request that the fact that he or she worked at the company be deleted. When a data subject enacts their right to be forgotten, their personal data needs to be either deleted or anonymised such that it can no longer be linked back to the individual.

How to automate responding to data subject requests

Below is a high-level diagram of the solution that automates the processes that need to be carried out to comply with the regulation.

Tool

This includes collecting data from different systems in order to fulfill a Subject Access Request and instructing systems to delete/anonymise data as part of a Right to be Forgotten request.

Process automation requires that asset inventories and data flows are first documented and personal data processing systems are identified.

The solution then integrates with system APIs and orchestrates data subject requests. It allows the operator (data privacy team) to generate a consumable report and carry out necessary identity verification checks before responding to the request. It also enables the operator to customise the report if needed.

This approach ensures personal data is collected or removed from all the systems in scope and accelerates the process of responding to the requestor within the 30-day period.

Early Stage Cybersecurity Accelerator Programme

HutZero

A few weeks ago I learnt that my application to attend the HutZero cyber entrepreneur bootcamp had been successful.  I am excited to start the programme next week and will keep you posted!

Whether you are just finishing your studies on cyber security, or have worked in the corporate world for a number of years, HutZero supports individuals at the very start of their entrepreneurial journey.

DevOps and Operational Technology: a security perspective

3391525700_187606bd23_z

I have worked in the Operational Technology (OT) environment for years, predominantly in major Oil and Gas companies. And yes, we all know that this space can move quite slowly! Companies traditionally employ a waterfall model while managing projects with rigid stage gates, extensive planning and design phases followed by lengthy implementation or development.

It’s historically been difficult to adopt more agile approaches in such an environment for various reasons. For example, I’ve developed architecture blueprints with a view to refresh industrial control assets for a gas and electricity distribution network provider in the UK on a timeline of 7 years. It felt very much like a construction project to me.  Which is quite different from the software development culture that typically is all about experimenting and failing fast. I’m not sure about you, but I would not like our power grid to fail fast in the name of agility. The difference in culture is justified: we need to prioritise safety and rigour when it comes to industrial control systems, as the impact of a potential mistake can cost more than a few days’ worth of development effort – it can be human life.

The stakes are not as high when we talk about software development.  I’ve spent the past several months in one of the biggest dot-coms in Europe and it was interesting to compare and contrast their agile approach to the more traditional OT space I’ve spent most of my career in. These two worlds can’t be more different.

I arrived to a surprising conclusion though: they are both slow when it comes to security. But  for different reasons.

Agile, and Scrum in particular, is great on paper but it’s quite challenging when it comes to security.

Agile works well when small teams are focused on developing products but I found it quite hard to introduce security culture in such an environment. Security often is just not a priority for them.

Teams mostly focus on what they perceive as a business priority. It is a standard practice there to define OKRs – Objectives and Key Results. The teams are then measured on how well they achieved those. So say if they’ve met 70% of their OKRs, they had a good quarter. Guess what – security always ends up in the other bottom 30% and security-related backlog items get de-prioritised.

DevOps works well for product improvement, but it can be quite bad for security. For instance, when a new API or a new security process is introduced, it has to touch a lot of teams which can be a stakeholder management nightmare in such an environment. A security product has to be shoe horned across multiple DevOps teams, where every team has its own set of OKRs, resulting in natural resistance to collaborate.

In a way, both OT and DevOps move slowly when it comes to security. But what do you do about it?

The answer might lie in setting the tone from the top and making sure that everyone is responsible for security, which I’ve discussed in a series of articles on security culture on this blog and in my book The Psychology of Information Security.

How about running your security team like a DevOps team? When it comes to Agile, minimising the friction for developers is the name of the game: incorporate your security checks in the deployment process, do some automated vulnerability scans, implement continuous control monitoring, describe your security controls in the way developers understand (e.g. user stories) and so on.

Most importantly, gather and analyse data to improve. Where is security failing? Where is it clashing with the business process? What does the business actually need here? Is security helping or impeding? Answering these questions is the first step to understanding where security can add value to the business regardless of the environment: Agile or OT.

Image by Kurt Kurasaki.