If you are building on AWS cloud infrastructure then security is almost certainly at the forefront of every move you make when designing, deploying and operating your network environments.
With large, complex environments, the ability to lock down your architecture and data is extremely important, 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.
Provided unauthorised parties don't have access to your admin consoles, a very effective way to ensure your network is safe, is to visualize how traffic can enter your network and to visualize what that traffic 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 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 potential 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. Knowing what is running where and who has access to what is only possible through visualization. Without visualization, vulnerabilities arising from misconfigurations can remain undetected for days, or weeks, or in the worst case scenario, when there has been 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 diagrams 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 Groups 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 freshly qualified 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 this AWS security group diagram view, you can see all of your security groups stacked on top of each other. These security group rows 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 in the attribute pane 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.
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 associated IAM policy to whatever it is that you are comfortable with, and Hava will work past any resources that can't be identified due to policy. This of course will limit the accuracy of the diagrams and security views.
Hava also supports and recommends AWS cross-account role access, Amazon's best practice methodology for 3rd party connectivity.
What DATA Does Hava Use?
Hava sync process imports data via the AWS API, 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?
The application database instance is configured to store all data at rest, additionally, column-level encryption of any secret credentials is 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 Hava 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.
Can you self host Hava?
Hava offers 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 Hava SaaS database and Applications hosted?
The current SaaS 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 - Learn more here:
