Techniques and Tools to secure Infrastructure

Techniques and Tools to secure Infrastructure

Author: Prabu Karuppiah

In this week's edition, we will cover some techniques (example scenarios and mitigations are in the full article) and tools to secure your Infrastructure. Let's start with two main attributes that are essential in reducing infrastructure-level breaches: awareness and communication.

Awareness begins with ensuring you first understand what you are building the service or application for and exploring what exactly could go wrong with it. Then, you must analyze and comprehend the system's needs and how it interacts with other elements in the network and the external world. Finally, you must explore how data will flow between all the components at every hand-off and examine them to see if there are any exploits at these hand-offs, and through this, become aware of the potential impact they pose. This process is known as Threat Modeling, which is a valuable framework that can guide us in defining the priorities of our implementation.

Now, the second and equally important part is ensuring that all of this gets communicated effectively to key stakeholders to obtain agreement and develop an effective action plan. This is critical as it will play a key role in determining the budget, timeline, release cycles, and personal needs, to name a few.

Tools

Protecting our cloud resources seems daunting and difficult at first. However, through the use of tools, we can better equip ourselves for the task. For instance, cloud providers have introduced their own tools to protect their users from attacks. These include such as Microsoft Defender for Azure, AWS IAM Access Analyzer, and AWS Config for AWS, and Security Command Center for GCP. There are also independent solutions out there that enable cloud-agnostic solutions to safeguard the infrastructure and provide compliance documents. 

In one of our previous posts we talked about an application that was designated as a Software as a Medical Device (SAMD) and was to go through an FDA approval process. In that context some of items that would need to be considered before finalizing an infrastructure monitoring service would be as follows:

  1. Since there will be a need to constantly monitor infrastructure, should we be run the service as a separate agent that we monitor and manage or can the service provider/cloud provider take up the responsibility?
  2. Will the monitoring provider provide us a dashboard of resource health, or will simply provide a vulnerabilities list?
  3. Are all resources from a Cloud Provider supported, or will only select types of resources viz. EC2 instances be monitored?
  4. Is it possible to integrate this as part of a CI/CD pipeline or will capabilities needs to be triggered as needed?
  5. How are vulnerabilities ordered? Do they list in the order of priority so that we can plan to fix the ones that can cause the most serious damage to our services?
  6. Does it support our particular compliance framework, e.g. HIPPA compliance?
  7. Does it alert us if any new types of threats have been found that impact our compliance standard?
  8. How much does this service cost, and do we get a free trial plan to test it?
  9. Finally, we will add a score based on our needs when choosing a service provider.

In the above example we scored two popular tools: orca.security, and wiz.io. In reality, these tools offer similar services, but for us it finally boiled down to Wiz due to the scaling preference as it supports new compliance frameworks that appear in the future and Orca does not. However, it is important to note Orca would most likely be cheaper. Again, as we stated in our previous article discussing static code analysis tools, it comes down to your personal and financial needs when building an application. Confidentiality, Integrity, and Availability (a.k.a CIA Triad) should be the driving principles of a well-built application. A properly built application should be able to serve its user needs and keep its data safe and secure. It should also be resilient to current attacks and proactive to future attacks. It is one thing to build a system that is secure with our current standards, but quite another to be aware and up to date with new types of attacks. That’s where logs and audit trails come into play. We will look at these in next week's edition.

Please find the full article here, to see example scenarios of infrastructure vulnerabilities and how they can be mitigated.

I hope you enjoyed this article, and please subscribe for the upcoming articles!

The Archimydes team

To view or add a comment, sign in

Insights from the community

Others also viewed

Explore topics