How to pass the AWS Security – Specialty exam

Security Badge

I previously wrote about how to prepare for the Certified Cloud Security Professional (CCSP) and AWS Certified Solutions Architect – Associate exams. Today,  I would like to focus on AWS Security – Specialty.

Exam cost aside, preparing for this specialty can be rather expensive. There is a whole industry around mock practice tests, study books, video tutorials and hands-on labs. Here I’ll aim to outline how to maximise the benefit while minimising costs, focusing on free resources.

Whitepapers, user guides and service FAQs

AWS documentation is arguably the best source of study material out there. I don’t know a single person who passed the exam without reading through at least some of them. Check out the official exam guide for the overview of domains to select the relevant ones. I focused on IAM, KMS, CloudTail, CloudWatch, VPC, Lambda, Inspector, GuardDuty, Athena, Macie and AWS Microsoft AD. At a very minimum, you should read these:

I also wrote about my experience in using security-related AWS services in my blog.

Online courses

Who needs paid for online tutorials when the AWS YouTube channel has a lot of their re:Invent talks available for free? There is literally a video on pretty much every subject you are interested in. There are too many to mention and you could conduct a simple search to find the latest talk on what you want, but I’ll recommend a few to get you started:

If you would rather have a structured online course instead and don’t mind paying a little bit for it, I recommend the Linux Academy and/or A Cloud Guru. I’ve done them both. Personally, I preferred the former as it had some hands-on labs, but A Cloud Guru is shorter and has some good exam tips. Besides, you can try both of them for free for 7 days and decide for yourself.

There is also the official AWS Exam Readiness: AWS Certified Security – Specialty course. It covers the exam structure, gives you tips on tackling questions and provides thorough explanations. I would save this one for last to get a view of your preparedness.

Practice tests

The obvious thing to do is to buy the official practice exam from AWS, right? Well, maybe not. Unless you’ve got it for free for passing one of the other AWS exams previously, you might be better off finding an alternative. It only includes 20 questions (which works out at $2 per question plus tax), and you don’t get to see the answers! Instead, you are presented with a pass/fail summary that gives you the overall percentage broken down by exam domains. You might be better off using the free 15 questions from Whizlabs, although I can’t recommend their paid products. Practice tests are also included in the Linux Academy and A Cloud Guru courses I mentioned above. Plus, the free official Exam Readiness course also comes with 24 questions with answers and explanations at the end. That should be enough to give you the feel for types of question on the exam.

Getting ready

When revising, I found some good notes and a mindmap from other students on the internet. You can also go through a set of flashcards (e.g.  on Quizlet) to recap on what you’ve learned.

With all this preparation, don’t lose track of why you are doing it in the first place: gaining the skills that you can apply in practice. The exam gives a good indication of your weaker areas and encourages you to fill these gaps. The best way to do this is, of course, through hands-on experience. If your organisation relies on AWS, find ways to apply the newly acquired knowledge there to make your cloud infrastructure more secure. If that’s not an option, there is always the Free Tier, where you can put your skills into practice. Finally, the Linux Academy (and some other providers) for a small cost offer you some hands-on labs and even a whole sandboxed playground for you to experiment in.

AWS constantly evolve and refine their services, and add new ones too. Keep this in mind while studying, as things move pretty fast in the cloud world. This also means that your learning is never finished, even if you pass the exam. But I think this is a good thing and I’m sure you agree!


AWS Security Hub: all your security alerts in one place

Security Hub

If you are following my blog, you’ve probably noticed that I’ve been focusing on security-specific AWS services in my previous several posts. It’s time to bring them all together into one consolidated view. I’m talking, of course, about the AWS Security Hub.

Security Hub allows you to aggregate and centrally analyse security alerts and findings from Config, GuardDuty, IAM, Inspector, Firewall Manager and more.

Security Hub findings

You can group, filter and prioritise findings from these services in many different ways. And, of course, you can visualise and make dashboards out of them.

CIS exampleApart from consolidating findings from other services, it also assesses your overall AWS configuration against PCI DSS and/or the CIS Amazon Web Services Foundations Benchmark, which covers identity and access management, logging, monitoring and networking, giving you the overall score (example below) and actionable steps to improve your security posture.

CIS score

Similar to the many other AWS services, Security Hub is regional, so it will need to be configured in every active region your organisation operates. I also recommend setting up your security operations account as a Security Hub master account and then inviting all other accounts in your organisation as members for centralised management (as described in this guidance or using a script).

If you are not a big fan of the Security Hub’s interface or don’t want to constantly switch between regions, the service sends all findings to CloudWatch Events by default, so you  can forward them on to other AWS resources or external systems (e.g. chat or ticketing systems) for further analysis and remediation. Better still, you can configure automated response using Lambda, similar to what we did with Inspector findings discussed previously.


Setting up a Web Application Firewall in AWS

WAF

I wrote about automating application security testing in my previous blog. If you host your application or API on AWS and would like an additional layer of protection agains web attacks, you should consider using AWS Web Application Firewall (WAF).

It is relatively easy to set up and Amazon kindly provide some preconfigured rules and tutorials. AWS WAF is deployed in front of CloudFront (your CDN) and/or Application Load Balancer and inspects traffic before it reaches your assets. You can create multiple conditions and rules to watch for.

WAF conditions

If you’ve been configuring firewalls in datacentres before the cloud services became ubiquitous, you will feel at home setting up IP match conditions to blacklist or whitelist IP addresses. However, AWS WAF also provides more sophisticated rules for detecting and blocking known bad IP addresses, SQL Injections and Cross Site Scripting (XSS) attacks.

Additionally, you can chose to test your rules first, counting the times it gets triggered rather than setting it to block requests straight away. AWS also throw in a standard level of DDoS protection (AWS Shield) with WAF at no extra cost, so there is really no excuse not to use it.


Automating the detection and remediation of security vulnerabilities in AWS

Inspector dashboard

If you rely on EC2 instances in at least some parts of your cloud infrastructure, it is important to reduce the attack surface by hardening them. You might want to check out my previous blogs on GuardDuty, Config, IAM and CloudTrail for other tips on securing your AWS infrastructure. But today we are going to be focusing on yet another Amazon service – Inspector.

To start with, we need to make sure the Inspector Agent is installed on our EC2 instances. There are a couple of ways of doing this and I suggest simply using the Inspector service Advance Setup option. In addition, you can specify the instances you want to include in your scan as well as its duration and frequency. You can also select the rules packages to scan against.

Inspector setup

After the agent is installed, the scan will commence in line with the configuration you specified in the previous step. You will then be able to download the report detailing the findings.

Inspector findings

The above setup gives you everything you need to get started but there is certainly room for improvement.

It is not always convenient to go to the Inspector dashboard itself to check for discovered vulnerabilities. Instead, I recommend creating an SNS Topic which will be notified if Inspector finds new weaknesses. You can go a step further and, in the true DevSecOps way, set up a Lambda function that will automatically remediate Inspector findings on your behalf and subscribe it to this topic. AWS kindly open sourced a Lambda job (Python script) that automatically patches EC2 instances when an Inspector assessment generates a CVE finding.

You can see how Lambda is doing its magic installing updates in the CloudWatch Logs:

Commadn line update

Or you can connect to your EC2 instance directly and check yum logs:

yum update

You will see a number of packages updated automatically when the Lambda function is triggered based on the Inspector CVE findings. The actual list will of course depend on how many updates you are missing and will correspond to the CloudWatch logs.

You can run scans periodically and still choose to receive the notifications but the fact that security vulnerabilities are being discovered and remediated automatically, even as you sleep, should give you at least some peace of mind.


Security lessons from the pandemic

49640411737_05b48fc1b0_c

The need for the digital transformation is becoming clear as the current pandemic is accelerating existing business and technology trends. Despite market uncertainty and tightening budgets, many companies are seeing improved productivity and cost savings through embracing remote working and cloud computing. They are recognising the value of being able to scale up and down the capacity based on customer demand and paying for only what they use rather than maintaining their own datacentres. Supporting staff and trusting them to do the right thing also pays off.

Security programmes must adapt accordingly. They should be agile and cater for this shift, helping people do their jobs better and more securely. Protecting remote workforce and your cloud infrastructure becomes a focus. It’s also a great opportunity to dust off incident response and business continuity plans to keep them relevant and in the forefront of everyone’s minds.

Work with your staff to explain the ways bad guys take advantage of media intense events for scams and fraud. Make it personal, use examples and relate to scenarios outside of the work context too. Secure their devices and know your shared responsibility model when it comes to cloud services. Backups, logging and monitoring, identity and access management are all important areas to consider. Overall, it’s a good time to review your risk logs and threat models and adjust your approach accordingly.

Photo by Chad Davis.


Continuous configuration and compliance monitoring with AWS Config

Config splash

I wrote previously about inventorying your assets in AWS using an external open source tool.  An alternative to this approach is to use AWS Config.

This AWS service certainly has its imperfections (e.g. it doesn’t support all AWS resources) but it is easy to set up and can be quite useful too. When you first enable it, Config will analyse the resources in your account and make the summary available to you in a dashboard (example below). It’s a regional service, so you might want to enable it in all active regions.

Config

Config, however, doesn’t stop there. You can now use this snapshot as a reference point and track all changes to your resources on a timeline. It can be useful when you need to analyse historical records, demonstrate compliance or gain visibility in your change management practices. It can also notify you of any configuration changes if you set up SNS notifications.

Config rules allow you to continuously track compliance with various baselines. AWS provide quite a few out of the box and you can create your own to tailor to the specific environment you operate in. You have to pay separately for rules, so I encourage you to check out pricing first.

As with some other AWS services, you can aggregate the data in a single account. I recommend using the account used for security operations as a master. You will then need to establish a two-way handshake, inviting member accounts and authorising the master account to be able to consolidate the results.

Member

 


Securing GSuite: a guide for startups

GSuite

GSuite is an excellent choice for any startup, especially early in the process of establishing your business. Its flexible cost structure allows you to pay per user while benefiting from range of services, including email (with a custom domain name), calendar, document collaboration and storage, videoconferencing and much more.

GSuite, being a Software-as-a-Service (SaaS), relieves you from the underlying infrastructure management in line with the shared responsibility model. This can be especially powerful for smaller companies trying out an idea, as it doesn’t require intensive capital expenditure to set up a datacentre or staff to maintain it. Startups, however, are still responsible for the data, permissions and overall configuration of GSuite if they want to keep their information secure.

Thankfully, Google made available a short checklist for small businesses, describing the necessary steps to safeguard company data. Similar guidance is available for larger (100+ users) organisations.

Settings 2

The plan you select will determine how many security features are available to you. Depending on the criticality of your data and the amount of control you require, it can be a good idea to upgrade to the Enterprise plan.

Hint: if you ask customer support to put you in touch with a sales representative and request a discount, it might just be given to you. Provided you are willing to commit to the subscription for a couple of years.

DashboardSecurity professionals will feel at home with the advanced features available after the upgrade. It includes encryption, data leakage prevention (DLP), granular access control and much more. Managing it is also going to become easier, as various reports and healthcheck dashboards are now at your fingertips.

Settings

Regardless of the plan you use, it won’t hurt to enable multi-factor authentication on all accounts, as it dramatically reduces the risk of account takeover. It might also be a good idea to backup your critical business data somewhere off GSuite for extra resiliency.


How to set up CloudTrail logging in AWS

I bet you already know that you should set up CloudTrail in your AWS accounts, if you haven’t already. This service captures all the API activity taking place in your AWS account and stores it in an S3 bucket for that account by default. This means you would have to configure the logging and storage permissions for every AWS account your company has. If you are tasked with securing your cloud infrastructure, you will first need to establish how many accounts your organisation owns and how CloudTrail is configured for them. Additionally, you would want to have access to S3 buckets storing these logs in every account to be able to analyse them.

If this doesn’t sound complicated already, think of a potential error in permissions where logs can be deleted by an account administrator. Or situations where new accounts are created without your awareness and therefore not part of the overall logging pipeline. Luckily, these scenarios can be avoided if you are using the Organization Trail.

Create Trail

Your accounts have to be part of the same AWS Organization, of course. You would also need to have a separate account for security operations. Hopefully, this has been done already. If not, feel free to refer to my previous blogs on inventorying your assets and IAM fundamentals for further guidance on setting it up.

Establishing an Organization Trail not only allows you to collect, store and analyse logs centrally, it also ensures all new accounts created will have CloudTrail enabled and configured by default (and it cannot be turned off by child accounts).

Trails

Switch on Insights while you’re at it. This will simply the analysis down the line, alerting unusual API activity. Logging data events (for both S3 and Lambda) and integrating with CloudWatch Logs is also a good idea.

Where can all these logs be stored? The best destination (before archiving) is the S3 bucket in your account used for security operations, so that’s where it should be created.

S3 bucket

Enabling encryption and Object Lock is always a good idea. While encryption will help with confidentiality of your log data, Object Lock will ensure redundancy and prevent objects from accidental deletion. It requires versioning to be enabled and is best configured on bucket creation. Don’t forget to block public access!

S3 block public access

You must then use your organisational root account to set up Organization Trail, selecting the bucket you created in your operational security account as a destination (rather than creating a new bucket in your master account).

For this to work, you will need to set up appropriate permissions on that bucket. It is also advisable to set up access for child accounts to be able to read their own logs.

If you had other trails in your accounts previously, feel free to turn them off to avoid unnecessary duplication and save money. It’s best to give it a day for these trails to run in parallel though to ensure nothing is lost in transition. Keep your old S3 buckets used for collection in your accounts previously; you will need these logs too. You can configure lifecycle policies and perhaps transfer them to Glacier to save on storage costs later.

And that’s how you set up CloudTrail for centralised collection, storage and analysis.


How to audit your AWS environment

Cloudmapper

Let’s build on my previous blog on inventorying your AWS assets. I described how to use CloudMapper‘s collect command to gather metadata about your AWS accounts and report on resources used and potential security issues.

This open source tool can do more than that and it’s functionality is being continuously updated. Once the data on the accounts in scope is downloaded, various operations can be performed on it locally without the need to continuously query the accounts.

One of interesting use cases is to visualise your AWS environment in the browser. An example based on the test data of such a visualisation is at the top of this blog. You can apply various filters to reduce complexity which can be especially useful for larger environments.

Another piece of CloudMapper’s functionality is the ability to display trust relationships between accounts using the weboftrust command. Below is an example from Scott’s guidance on the use of this command. It demonstrates the connections between accounts, including external vendors.

weboftrust

I’m not going co cover all the commands here and suggest checking the official GitHub page for the latest list. I also recommend running CloudMapper regularly, especially in environments that constantly evolve.

An approach of that conducts regular audits. saving reports and integrating with Slack for security alerts is described here.


AWS security fundamentals: IAM

IAM

Here I am going to build on my previous blog of inventorying AWS accounts and talk about identity and access management. By now you have probably realised that your organisation, depending on its size, has more accounts with a lot of associated resources than you initially thought. The way users are created and access is managed in these accounts has a direct impact on the overall security of your infrastructure.

What accounts should your company have? Well it really depends on the nature of your organisation but I tend to see the following pattern for software development driven companies:

1. Organisation root. Your organisation root account should be used to create other accounts (and some other limited amount of operations) and otherwise shouldn’t be touched. Secure the credentials and leave it alone. It should not have any resources associated with it.

2. Identity. Not strictly necessary to have a separate account for this but isn’t it great to be able to manage all your users in a single account?

3. Operations. This account should be used for log collection and analysis. Your security team will be happy.

4, 5 and 6. A separate account for your development, staging and production environments. It’s a good idea to separate them for the ease of managing permissions and pleasing auditors.

Users and services that are managed within an AWS account, should only get access to what they need.

Security specialists are spending a great deal of their time reviewing firewall rules when working on their on-premise infrastructure to ensure they are not too permissive. When we move to the cloud, these rules look somewhat different but their importance has only increased.

To demonstrate the relationship between accounts, users, groups, roles and permissions, let’s walk through an example scenario of a developer in your company requiring read only access to the staging environment.

No automation or anything even remotely advanced is going to be discussed here as we are just covering the basics in this blog. It is no less important, however, to get these right. The principles discussed here will lay the foundation for more advanced concepts. Again, the terminology here is specific to AWS but overarching principles can be applied to any cloud environment.

To start with this scenario, let’s create a custom role CompanyReadOnly and attach an AWS managed ReadOnlyAccess policy in the Permissions tab.

Role Policies
CompanyReadOnly ReadOnlyAccess

This role allows a trusted entity (an account in this case) to access this account. When you access this account you will get the permissions defined in the policy.

Let’s say we have an account where all users are managed (the Identity account in point 2 in the list above). In this account, create a custom policy CompanyAssumeRoleStagingReadOnly allowing assuming the right role, where 123456789012 is Staging account ID which is the trusted entity for the Identity account:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": "arn:aws:iam::123456789012:role/CompanyReadOnly"
        }
    ]
}

Now let’s create a custom StagingReadOnly group and attach the above policy in the Permission tab.

Group Permissions
StagingReadOnly CompanyAssumeRoleStagingReadOnly

Finally add a user to that group:

User Group Permissions
Developer StagingReadOnly CompanyAssumeRoleStagingReadOnly

In this group additional permissions can be added, e.g. AWS managed enforce-mfa policy for mandatory multi-factor authentication.

Of course, granular policies specifying access to particular services rather than blanket ReadOnly is preferred. Remember the aim here is to demonstrate IAM fundamental principles rather than recommend specific approaches you should use. The policies will depend on the AWS resources your organisation actually uses.