How to inventory your AWS assets

Resource

Securing your cloud infrastructure starts with establishing visibility of your assets. I’ll be using Amazon Web Services (AWS) as an example here but principles discussed in this blog can be applied to any IaaS provider.

Speaking about securing your AWS environment specifically, a good place to start is the AWS Security Maturity Roadmap by Scott Piper. He suggests identifying all AWS accounts in your organisation as a first step in your cloud security programme. 

Following Scott’s guidance, it’s a good idea to check in with your DevOps team and/or Finance to establish what accounts are being used in your company. Capture this information in a spreadsheet, documenting account name, ID, description and an owner at a minimum. You can expand on this in the future to track compliance with baseline requirements (e.g. enabling CloudTrail logs).

Once we have a comprehensive view of the accounts used in the organisation, we need to find out what resources these accounts use and how they are configured. We can get metadata about the accounts using CloudMapper’s collect command. CloudMapper is a great open source tool and can do much more than that. It deserves a separate blog, but for now just check out setup instructions on its GitHub page and Scott’s detailed instructions on using the collect command.

The CloudMapper report will reveal the resources you use in all the regions (the image at the top of this blog is from the demo data). This can be useful in scenarios where employees in your company might test out new services and forget to switch them off or nobody knows what these services are used for to begin with. In either case, the company ends up paying for these, so it makes economic sense to investigate, and disabling them will also reduce the attack surface.

In addition to that, the report includes a section on security findings and will alert of potential misconfigurations on the account. It also provides recommendations on how to address them. Below is an example report based on the demo data. 

Findings

As we are just establishing the view of our assets in AWS at this stage, we are not going to discuss remediation activities in this blog. We will, however, use this report to understand how much work is ahead of us and prioritise accordingly.

Of course, it is always a good idea to tackle high criticality issues like publicly exposed S3 buckets with sensitive information but don’t get discouraged by a potentially large number of security findings. Instead, focus on strategic improvements that will prevent these issues from happening in the future.

To lay the foundation for a security improvements programme at this point, I suggest adding all the identified accounts to an AWS Organisation if you haven’t already. This will simplify account management and billing and allow you to apply organisation-wide service control policies.


Security product management

In one of my previous blogs I wrote about building a security startup. Here I would like to elaborate on the product management aspect of a venture.

There are many businesses springing up in the cybersecurity space at the moment. A lot of them are developed by great technologists yet still struggle. The market conditions might be right and the product itself can be secure but it often fails to get traction.

When I’m asked why this might be and what to do about it, my immediate response is to dive deeper and understand the product management function.

In truth, it’s not enough to have a technically flawless solution, it has to align with what your customers want. Moreover, the bar in new product adoption is high. As Nir Eyal famously pointed out in his book Hooked, “for new entrants to stand a chance, they can’t just be better, they must be nine times better … because old habits die hard and new products or services need to offer dramatic improvements to shake users out of old routines. Products that require a high degree of behaviour change are doomed to fail even if the benefits of using the new product are clear and substantial.”

Thankfully, it’s not all doom and gloom – there are things you can do to overcome this challenge. 

Depending on the stage of your venture, the most important question to answer is: are people using your product? If not, get to the point where customers are using your product as fast as you can. Then talk to them and learn from them. Find out what problem they are trying to solve.

Provide that solution and measure what matters (revenue, returning usage, renewal rate) and build measurement targets and mechanisms into your specifications.

Disciplined product management is there to bridge the gap between business (sales and marketing) and technology teams. As a product manager, you should support these teams with market analysis, planning, prioritisation, design and measurement based on customer feedback.

Knowledge of the customer and their needs will help define your strategic position and overarching guiding principles to support decision-making in the company.

That strategy in turn should be supported by tactical steps to achieve the vision. We are now beginning to shape actual work deliverables and help the technology teams prioritise them in your development sprints.

Principles described here are applicable in any type of organisation, it doesn’t have to be security specific. The industry you are in matters less than the company culture.

People often focus on tools when talking about product management or adopting agile development. The reality is that it’s often about the culture of collaboration. Break the silos, make sure customer feedback is guiding the development and don’t lose sight of the strategy. Your customers will love it, I promise.