Best Security Practices for Microsoft Azure: Stay Vigilant
In previous posts (Part 1 and Part 2), I discussed various security best practices and controls to help create a “defense in-depth” security posture in Microsoft Azure. I guess the job should be done if we have managed and implemented these properly, right? Think again. No matter what you have done, there is no such thing as being“100 percent secure.”
Our goal should be to perform due diligence and protect our assets the best we can but, make no mistake, there will always be a security hole in our implementation, and any motivated attacker will find it.
The question is not “can they?” but instead “when will they?”
Quick trivia question: What movie is this from? “Hope is a good thing, maybe the best of things and no good thing ever dies.” Anyone? Go ahead and hope that you will never be breached and live the “Charlie and the Chocolate Factory” dream for a while. However, if you don’t want to daydream, then hope for the best and prepare for the worst. This brings us to the importance of an established Incident Response Process (IRP), which should be followed when an incident occurs (e.g. a vulnerability being found).
Consider the benefits when workloads are running in the cloud and how to take advantage of the Azure cloud to automate your IRP.
Traditional Response Flow vs Azure Response Flow: The No. 1 goal is to have a successful recovery as fast as possible. In a traditional response flow, the first thing to do when an incident occurs is to isolate the server and take the workload out of service. Let’s take an example of an incident and see how your recovery approach differs in traditional response vs in Azure.
After an incident the first thing you do is isolate the server, taking your workload out of the service. This is where the clock starts and it’s imperative to restore service as quickly as possible. Next, you analyze and try to identify the cause of the incident, and then begin the repair process to see if an improvement can be made to avoid a reoccurrence. Once this cycle is complete, you can bring the replacement online and hit the timer’s stop button.
However, when moving to the cloud, you can bring in the replacement server more quickly and conduct the analyses on the snapshot of the server by automation. This allows for a faster return time to service and more time to perform analyses. One argument against this approach is the question of “what did we gain with this?” Bringing in the replacement server without being repaired will just reintroduce the problem. This approach starts a game with the attacker that will kick them out, stopping further penetration into your environment.
By using this method, you have minimized the service impact and made infiltration more difficult. This game can run in parallel while you focus on analyzing and identifying the problem, fixing it on the replacement server and, knocking the hacker off completely.
Vulnerability Assessment and Penetration Testing: So how do we ensure we measure our own weakness? This is where vulnerability assessment and penetration testing comes into play.
The main objective of the vulnerability assessment (VA) is to find as many vulnerabilities as possible that an attacker can leverage to cause destruction to an organization. There are many self-servicing tools that can be used to conduct vulnerability assessments. However, it is recommended a trained security assessor, either internally or externally, perform this assessment. Their fresh set of eyes may detect more security flaws and can help fine-tune existing security controls, or recommend adding more.
To evaluate the security of your implementation, consider doing a post-VA penetration test to safely exploit system vulnerabilities, including OS service and application weaknesses. By conducting the VA, you have identified the vulnerabilities, but not the potential consequences if they are exploited. Therefore, penetration testing is very useful in validating the effectiveness of the defensive mechanisms.
Azure understands the importance of penetration testing in any secure application deployment and has established a policy for its customers to request permission to conduct penetration tests.
These exercises will help you determine if the implemented security controls can withstand real-world attacks. Afterward, you can begin the remediation steps which can be as simple as closing a port, turning off a service or, in other cases, it can require a software patch or a rule from an intrusion prevention system. No matter how it is accomplished, it is important to verify that remediation is in place and protecting the vulnerability.
Finally, you must stay involved and maintain your security practice because requirements will evolve and, you will need to evaluate these changes from a security perspective and deploy updated, or new controls. It is key to ensure that the ongoing management aspect of security continues, which may involve documenting implemented controls and monitoring changes.
I hope this series has provided the information you need to secure your Azure environment with confidence – not just providing by providing a list of tasks to be performed but by showing how you can tackle it without compromising the speed and agility of the cloud itself.
A summary of these strategies is also covered in a recently released joint webinar with Microsoft Azure and Trend. Watch the on-demand webinar to see how much you can accomplish with better, proven security optimized to protect cloud workloads.
from Trend Micro Simply Security http://ift.tt/1BjPwBe
via IFTTT