One of the benefits of using Azure for application testing and deployment is that you can quickly get environments created. You don’t have to worry about requisitioning, acquiring, and “racking and stacking” your own on-premises hardware.
This is great – but you still need to make sure you perform your normal security due diligence. One of the things you likely want to do is penetration test the applications you deploy in Azure.
1. Traditional Security Methodology
Traditional security methodologies have largely been focused on prevention. Prevention is a defensive strategy aimed at eliminating vulnerabilities and thereby mitigating security breaches before they happen.
An example of a prevention strategy is how Microsoft limits operator/administrator access to employees who have a demonstrated need for access and who meet eligibility requirements (for example, passed a background check, met all compliance and security requirements, in a job function/role that requires access, etc.). Furthermore, administrators maintain zero standing permissions and instead they are given Just-In-Time (JIT) access1 and Just Enough Administration (JEA) . Other examples include segregating the employee email environment from the production environment and the use of specialized, highly secure hardened workstations for performing sensitive operations. Wherever possible, human intervention is replaced by automated, heavily audited, tool-based processes. Some examples of routine functions include deployment, debugging, diagnostic data collection and service administration. Microsoft Online Services continue to invest in systems security and operations automation in order to reduce exposure to potential security risks.
2. New and Emerging Threats
During the past five or more years, one specific threat category has become much more widely discussed. Advanced Persistent Threat (APT) was a term coined to refer to nation-state sponsored attempts to infiltrate military, defense industrial base, and government networks with the specific goal of exfiltrating sensitive data. Today, the term APT is used widely in media and security circles to describe any attack that seems to specifically target an individual organization, or is thought to be notably technical in nature regardless of whether the attack was actually advanced or persistent. Common characteristics of an APT include:
Practiced tool usage
3 Assume Breach Methodology
3.1 Assume Breach Execution
Assume Breach in Microsoft cloud services was initially carried out via wargame and then actual breach exercises, called Red Team breaches, intended to simulate real-world attacks. Red Team breaches test Microsoft’s abilities to respond to targeted and persistent attacks with the goal of significantly reducing the Mean-Time to Detect (MTTD) and Mean-Time to Recovery (MTTR) .
Prior to dedicating resources to all out Red Team breaches, at Microsoft, we started with tabletop exercises called wargames. Wargame exercises are akin to SDL Threat Modeling, though geared to the security response process and personnel of an organization or service dealing with an attack. The intent of wargaming is improving security incident response procedures by engaging personnel from different groups inside Microsoft – from Security to Engineering and Operations. As we initiated and continued wargames in more and more depth, it became clear which groups or representatives we were missing and needed to be engaged.
3.3 Red Teaming
The strategy is executed by two (2) core groups: the Red Team (attackers) and the Blue Team (defenders) . Referred to as Red Teaming, the approach is to test Microsoft Azure and Office 365 systems and operations using the same Tactics, Techniques and Procedures (TTPs) as real adversaries, against live production infrastructure, without the foreknowledge of the infrastructure and platform Engineering or Operations teams. This tests security detection and response capabilities, and helps identify production vulnerabilities, configuration errors, invalid assumptions or other security issues in a controlled manner. Every Red Team breach is followed by full disclosure between the Red Team and Blue Team to identify gaps, address findings and significantly improve breach response.
Companies industry-wide are faced with the harsh reality that they may have been living in a constant state of compromise. This is made worse by the fact that a large number of companies remain blissfully unaware that they, too, are breached. Today’s threat landscape requires reducing exposure to attacks including insider threats. The most imperative change requires organizations to significantly decrease the mean time to detection and recovery from a breach.
Red Teaming has become one of the most essential parts of developing and securing Microsoft’s infrastructure, platform and services. The Microsoft Azure and Office 365 Red Teams impersonate sophisticated adversaries and allows Microsoft to validate and improve security, strengthen defenses and drive greater effectiveness of its enterprise cloud security programs. Through regular live site attack and penetration, Red Team breaches provide the critical means to practice security incident response as well as accurately measure readiness and the impacts of real-world attacks. Customers can be confident that Microsoft is continuously improving protection, detection and response in the process of striving to deliver more secure cloud services.
If you would like to formally document an upcoming penetration testing against your applications hosted in Microsoft Azure, Let us write on firstname.lastname@example.org