If you look after AWS cloud infrastructure then security is no doubt at the forefront of every move you make when designing, deploying and operating your network environments.
With large, complex environments the need lock down your infrastructure and data is paramount, so anything that makes the job easier and doesn't involve trawling through network logs and thousands of console settings can only be a good thing.
Central to the Cloud Security Alliance's "Security guidance critical areas of focus in cloud computing v4.0" are a series of visualisations laying out the definitions and subtleties between Software as a service, Infrastructure as a service and the more complex Platform as a service. In each scenario, the responsibility for security is weighted somewhere between the provider (100% for SaaS) and the App developer / end user. At all levels, the ability to visualise infrastructure and the security associated with it is paramount.
Provided bad actors don't have access to your admin consoles, the most effective way to ensure your network is safe, is to visualize how traffic can enter your network and to visualize what they would be able to access. This is of course best done proactively. If you are checking access logs to see who got in and how, then it's probably a bit late. Getting to know your publicly visible attack surface is a good starting point.
With new methodologies like DevOps comes the idea of Infrastructure as Code (IaC), in which infrastructure is automated, managed and provisioned by machine-readable definition files. This API-driven approach is a core premise of automated cloud-first environments because it makes it easy to change the infrastructure on the fly, however it also makes it easy to program in misconfigurations that leave the environment open to vulnerabilities. Gartner states that 95 percent of all security breaches are due to misconfigurations, and those mistakes cost companies nearly $5 trillion in between 2018 and 2019 alone.
Underlying these automation issues is the greatest vulnerability of all: Lack of Visibility. In environments as fluid and complex as enterprise cloud deployments, there are hundreds or thousands of instances and accounts, and knowing what or who is running where and doing what is only possible through visualization. Without that help, vulnerabilities arising from misconfigurations can remain undetected for days, or weeks, or the worst case scenario, when there is a breach.
Cloud security posture management addresses these issues by continuously monitoring risk in the cloud through prevention, detection, response, and prediction of where risk may appear next, however giving experienced engineers line of sight through well laid out visualizations can give you a head start over CPMA automation.
As part of the AWS Diagram set automatically created by Hava when you connect your AWS read-only account credentials is the security group view.
AWS Security Group Architecture Diagram
With the standard infrastructure view built by Hava, you get to see your network gateways and the availability zones, VPC's and subnets that are present and the connections between the gateways and individual resources.
The above security group view comes at the network configuration from another angle. The diagram lays out all the discovered security groups and overlays the ports and traffic ingress / egress details.
Whether you are fresh out of Cloud Security Certification or a wizened battle scarred cloud security engineer, the ability to immediately see all your ports and potential vulnerabilities on one diagram is incredibly useful. At a glance, you can see whether the security has been configured in line with your cloud security architect's intentions and that nothing has been missed or left vulnerable.
On the above 'demo' environment you can immediately see port 443 is wide open.
On the initial AWS security diagram view, you can see all of your security groups stacked on top of each other. These security groups are interactive. If you can see an open port and want to know what resources are governed by the security group, all you need to do is click on the group and the attribute information pane to the right of the diagram changes to display that information.
Selecting the "Demo-Internal-Servers" security group on the above diagram for instance, changes the attribute pane metadata. Now we can see specific details about the group like:
- Region
- Ingress Ports and IP addresses
- Egress Ports and IP addresses
- Connected resources EC2 instances / Network Interfaces / Load Balancers
- Tags
Most of these resources are also 'selectable', so you can dig deeper into each resource from the security attribute pane should you need to without leaving the security group view diagram.
If you are recommending particular cloud security group frameworks as part of a cloud security solutions offering or are a cloud security services consultant or engineer, you can probably appreciate how much time you could save adding Hava's security view diagrams to your engineering tool set.
How secure is Hava?
The irony isn't lost on us. The first question security consultants ask is how does Hava work and can we host it on our own infrastructure to ensure the ultimate secure environment. We have achieved Soc2 Type 2 Compliance.
What CREDENTIALS Does Hava Require?
AWS keys are stored within our database using AES encryption, but we also promote and prefer using Amazon Cross Account Roles for allowing access. Finally, you are free to tighten the IAM policy to whatever it is that you are comfortable with, and Hava will work past any resources that can't be identified. This of course will limit the accuracy of the diagrams and security views, we must be able to retrieve a rudimentary amount of the EC2 data to create anything useful.
Hava also supports and recommends AWS cross-account role access, Amazon's best practice methodology for 3rd party connectivity.
What is the IMPACT OF Hava FAILING in a self Hosted Scenario?
Hava does not operate within the critical path of any user's workflow. Due to the nature of the service and the way Hava reads config data from the user's cloud provider, the only impact of Hava not working would be the functionality of updating an existing, or creating a new diagram.
What DATA Does Hava Use?
Hava imports users data via the AWS APIs, the basic level of information it requires to generate a useful visualization centers around the AWS EC2 service. We offer a variety of flexible IAM policy configurations that can allow or deny access to certain calls based on the users security policy and comfort of the service. This allows for a "progressive enhancement" style algorithm depending on the access granted to certain resources. You are in control of what Hava can see.
What DATA Does Hava STORE?
Hava stores metadata around each running service (i.e. resource ids, configuration values, current metrics) to allow diagrams to be identified and created. Hava imports no data from within user services, but users are welcome to alter the IAM policy to allow a level of access they're comfortable with.
IS Hava Data ENCRYPTED?
Our database instance is configured to store all data at rest, additionally, column-level encryption of any secret credentials are performed to ensure that data cannot be decrypted without a private key from the application server, this helps protect against potentially harmful SQL injection attacks.
WHAT PROTECTION IS IN PLACE AGAINST UNAUTHORISED ACCESS?
Hava takes security very seriously, only a core group of trusted employees have access to production data. Encryption is used by default for all network communication, and is also used within the database for any credentials. SSH and network-level access is disallowed on all servers, and we follow the principles of immutable artifacts and infrastructure to ensure what is tested is what is deployed.
WHAT CONTROL CAN WE HAVE?
Hava can offer a self hosted solution for any users who must maintain control over where data is stored and accessed. If you have internal policies or geo-political governance that dictates where data can be stored, we are happy to arrange a self-hosted instance of Hava to build and store both yours and your client's diagrams and metadata.
Where are The Standards Hava SaaS database and Applications?
The current production environment is currently located within USA. If you have specific needs for this data to be stored elsewhere, please get in touch with us.
If you would like to discuss your particular use case for Hava security visualizations and fully automated AWS infrastructure diagrams, please get in touch via chat or email.
You can jump straight in and try Hava SaaS for free here:
