Category Archives: cybersecurity policy

4 best practices to help you integrate security into DevOps

Microsoft’s transition of its corporate resources to the cloud required us to rethink how we integrate security into the agile development environment. In the old process, we often worked on 6- to 12-month development cycles for internal products. The security operations team was separate from the application development team and was responsible for ensuring that applications met security requirements. There was time to troubleshoot security between the two teams. Once we shifted to a shorter development cycle, we had to compress the new process to bake security into DevOps.

Our experience has led us to adopt four best practices that guide our thinking about integrating security with DevOps:

  1. Inventory your cloud resources.
  2. Establish a governance structure for cloud services.
  3. Give DevOps accountability for security.
  4. Redefine centralized security.

This post walks you through these tenets with some advice we hope you can apply to your own organization.

Inventory your cloud resources

Cloud subscriptions are so easy to spin up that many organizations don’t have a comprehensive understanding of which teams are using which services. This makes it challenging to manage your costs and enforce security policies. If you are uncertain which services you are currently paying for, billing is good place to start.

Establish a governance structure for cloud services

Once you understand your cloud inventory, you can begin the work of making sure your investments align with your business strategies. This may mean limiting which services your organization uses to maximize the ones that will help you meet your business goals. Then, align your organization to your cloud strategy by defining a governing structure:

  • Develop business scenarios that define acceptable use and configuration of cloud resources.
  • Define architecture and patterns for the cloud services you plan to use.
  • Limit who can create new subscriptions.

Give DevOps accountability for security

The only way to effectively enforce security policies in a short development cycle is to integrate security into the application development process. Early in our evolution, we dropped security team members into application development teams to create a single team with shared goals. This revealed cultural challenges and unexamined assumptions. Initially, both the application developers and the security team expected to conduct their jobs as they had in the past. Application developers wrote code and then security operations queued up issues to address. This proved unworkable for two reasons. Security analysts were queuing up too many security tasks to fit within the cycle. The application developers were often confused because security operations underestimated how well they understood the nuances of security.

The only way to meet our goals was to shift accountability for security to the DevOps teams. We wanted application developers to try to solve security issues as part of their process. This required education, but we also implemented some practices that encouraged the team to take on that responsibility:

  • Secure DevOps Kit for Azure—The Secure DevOps Kit for Azure provides scripts that can be configured for each resource. During development and before production, DevOps can easily validate that security controls are at the right level.
  • Security scorecard—The scorecard highlights which members of the team are skilled at addressing security and encourages people to improve and collaborate with each other.
  • Penetration testing—When a red team conducts a penetration test of an application, the results typically inspire the team to take security more seriously.

Redefine centralized security

We experimented with eliminating a central security team entirely, but ultimately, we realized that we needed a centralized team to monitor the big picture and set baselines. They establish our risk tolerance and measure security controls across subscriptions. They also automate as much of the security controls as they can. This includes configuring the Secure DevOps Kit for Azure. This team also needed training to better understand the vulnerabilities of the cloud. Tabletop exercises to talk through possible attacks with red teams was one way they got up to speed.

As our evolving process suggests, our biggest challenge was shifting culture and mindset. We recommend that you take time to define roles and start with a small team. You can expect to continuously discover better ways to improve teamwork and the security of your process and your applications.

Get started

For more details on how we evolved our security process for the cloud, watch the Speaking of security: Cloud migration webinar and get the Secure DevOps Kit for Azure.

The post 4 best practices to help you integrate security into DevOps appeared first on Microsoft Security.

Demystifying Password Hash Sync

This blog is part of a series of posts providing a behind-the-scenes look of Microsoft’s Detection and Response Team (DART). While responding to cybersecurity incidents around the world, DART engages with customers who are wary about using Password Hash Sync (PHS) or are not utilizing this service’s full capabilities. As customers can gain tremendous security benefits using the full capabilities of this service, we want to demystify PHS.

What PHS is and is not

What is PHS? First, let’s start with what it is not. PHS doesn’t sync actual passwords. Rather, it syncs the hashes of passwords, which have all undergone a per-user salt and 1,000 iterations of the HMAC-SHA256 key hashing algorithm, before being sent to Azure Active Directory (Azure AD). Through our hands-on experiences, we’ve learned that many companies believe that Microsoft may have access to users’ passwords. Microsoft is committed to protecting your privacy, and it’s important to note that the SHA256 hash cannot be decrypted—so the plain-text version of the password is never and can never be exposed to Microsoft.

The second important consideration of PHS is that, with PHS your Identity Management provider is moved from your current provider to Azure AD. This allows the organization to move from an Identity Management provider—which is typically an on-premises server and requires maintenance and potentially server downtime—to a platform-as-a-service (PaaS) provider.

From a security perspective, organizations gain significant reliability advantages and improved capabilities by moving to PHS, including Smart Lockout, IP Lockout, and the ability to discover leaked credentials, as well as the benefits of utilizing Microsoft’s billions of worldwide data points as additional layers of security to your organization’s environment.

More about these key features:

  • Smart Lockout assists in blocking bad actors who are attempting to brute force passwords. By default, Smart Lockout locks the account from sign-in attempts for one minute after ten failed attempts. Smart Lockout tracks the last three bad password hashes to avoid re-incrementing the lockout counter. For more information Smart Lockout, see Azure AD Smart Lockout.
  • IP Lockout works by analyzing those billions of sign-ins to assess the quality of traffic from each IP address hitting Microsoft’s systems. With that analysis, IP Lockout finds IP addresses acting maliciously, such as an IP that is password spraying the tenant, and blocks those sign-ins in real-time, while allowing the real user to continue to successfully sign in.
  • Microsoft Leaked Credentials Service acquires username/password pairs by monitoring public web sites and the Dark Web and by working with:
    • Researchers
    • Law enforcement
    • Microsoft Security teams
    • Other trusted sources

When the service acquires username/password pairs, the passwords are sent through the same hashing algorithm and are checked against Azure AD users’ password hashes. When a match is found (indicating a compromised credential), a “Leaked Credentials Risk Event” is created. Please see Azure AD Risk Events for additional information regarding Leaked Credentials.

Another important benefit to PHS is that, should your tenant experience a Denial of Service (DoS) and/or Password Spray attack, Microsoft will take the brunt of that traffic. That traffic is directed at Microsoft, not your on-premises Active Directory Federated Services (AD FS). When authentication happens via on-premises AD FS your server is responsible for managing the load and potentially causing downtime.

Moving an organization’s identity management provider to Azure AD and utilizing Password Hash Sync allows for both an increase in overall security posture and reduced management overhead. The security benefits, including leaked credentials, IP lockout, and Smart Lockout, all utilize Microsoft’s telemetry that gives organizations the power of Microsoft’s intelligence.

NOTE: If PHS is the secondary authentication method and, if you choose to take advantage of Smart Lockout and IP Lockout, the primary authentication method must support these functionalities. PHS is recommended as secondary in a hybrid environment if Federated or Pass-through Authentication is primary as a redundancy mechanism, as well as the ability to collect information for Leaked Credentials.

Learn more

To learn more about DART, our engagements, and how they are delivered by experienced cybersecurity professionals who devote 100 percent of their time to providing cybersecurity solutions to customers worldwide, please contact your account executive. Also, bookmark the Security blog to keep up with our expert coverage on security matters and follow us at @MSFTSecurity for the latest news and updates on cybersecurity. Read DART: the Microsoft cybersecurity team we hope you never meet for more about the DART team.

The post Demystifying Password Hash Sync appeared first on Microsoft Security.

UK launches cyberstrategy with long-term relevance

Like most major global economies, the United Kingdom continues to place cybersecurity issues front and center. The National Cyber Security Strategy: 2016-2021 document—published by the UK Government and released nearly two years ago—describes the plan to make the UK secure and resilient in cyberspace. It’s the most frequently referenced document and project in any cybersecurity discussion. After two years, and with recent updates, it’s worthwhile to revisit the document to assess its importance in securing digital transformation across the UK’s economy. Moreover, the National Security Capability Review (NSCR) March 2018 update to the National Cyber Security Strategy makes the timing for a review of this all the more relevant, as the 80-page document is well-written, thorough, and remains useful and relevant. The cyberstrategy’s core pillars—defend, deter, and develop—are described in detail and address a wide array of important topics, including education, international cooperation, and public-private collaboration.

Specifically, the cybersecurity document does an excellent job in the following areas:

  • Insider threats—This type of threat is highlighted throughout the document; something that is not always emphasized sufficiently. For example, “Insider threats remain a cyber risk to organizations in the UK. Malicious insiders, who are trusted employees of an organization and have access to critical systems and data, pose the greatest threat.” We continue to hear about this problem from customers in nearly all industries and in all countries. This bold and clear statement makes it clear that this problem is front and center for the UK strategy, as it should be.
  • Public incidents—It’s refreshing to see major incidents that impact companies and organizations in the UK highlighted rather than hidden from public view. The document includes several incidents, such as the 2015 TalkTalk breach, and the 2016 attack on the Society for Worldwide Interbank Financial Telecommunication (SWIFT) payment system in Bangladesh, the Philippines, and the Ukrainian power grid incident. While these incidents did not all occur on UK soil or directly to UK organizations, their impact was still felt in the UK.
  • Diversity and inclusion—The UK is committed to increasing diversity while also addressing its cybersecurity skills shortage. The document states emphatically that “we will address the gender imbalance in cyber-focused professions, and reach people from more diverse backgrounds to make sure we are drawing from the widest available talent pool.” The need is so critical that cybersecurity has become known as a wonderful field for younger professionals to embark on a new career, even if it is not something that is well-known.
  • Public-private collaboration—Cybersecurity is a “team sport” and working together across private and public sectors is essential. Openly admitting this and accepting government responsibility is a key tenet of this strategy, described as, “Government has a clear leadership role, but we will also foster a wider commercial ecosystem, recognizing where industry can innovate faster than us.” The document also states, “We will set out more clearly the respective roles of government and industry, including how these might evolve over time.”

As we look at other areas that the strategy may wish to consider expanding into or elaborating upon in the coming years, three specific areas come to mind:

  • Links to money laundering and terrorist financing—While the initial 2016 version did not mention how the flow of money impacts and funds cybercrime, the NSCR March 2018 update did, with three specific references to money laundering and terrorist financing, explaining, “We will take a whole-of-government approach including with the Devolved Administrations to tackle serious and organized crime and publish an updated Serious and Organized Crime Strategy in 2018.” It also stated, “We remain a leading player in developing and applying economic sanctions [… and will] … continue using sanctions smartly to deliver national security outcomes after we have left the EU.”
  • Returning military veterans—Whether it be from armed conflicts or peace-keeping missions or other such activities, one way the UK could shrink the gap in cybersecurity skills would be to help military veterans transition into this field. The strategy states, “This skills gap represents a national vulnerability that must be resolved.” To that end, there are multiple paths that other countries have pursued that could be applied here.
  • Cloud computing—The terms “cloud” and “cloud computing” are not mentioned in the original 2016 strategy document or in the NSCR March 2018 update. Cloud-based security offerings are a mainstay of any cybersecurity strategy and bring with them enormous benefits, speed, operational efficiencies, and more.

Looking ahead, it is inspiring to see that in the NSCR March 2018 update to the National Cyber Security Strategy there is a real commitment to maintaining the course with the original 2016 strategy. The 2018 update states quite openly that “the NSCR cyber project confirms that our overarching strategic objectives still stand” and “We will continue to implement the National Cyber Security Strategy and ensure it keeps pace with the threat.”

Clearly the UK will stay the course with its original cybersecurity strategy with additional changes and enhancements. Moreover, with all eyes on the UK transition out of the EU, it’s important to demonstrate to the world community that cybersecurity strategy can not only exist but in fact can thrive even amid a massive overhaul in international geopolitics.

The post UK launches cyberstrategy with long-term relevance appeared first on Microsoft Security.

Announcing the all new Attack Surface Analyzer 2.0

Few of us know what is really happening on our systems when we install new software from new or untrusted sources. This is important because most installation processes require elevated privileges, which can lead to undesired system configuration changes. Knowing what changes have been made is vital to maintaining the security of your system, data, and networks. Identifying those changes can be challenging and time consuming without a little help.

The classic Attack Surface Analyzer 1.0 was released in 2012 to help software developers and IT professionals identify changes made to Windows operating systems during application installations. This year, we decided to rewrite the tool to take advantage of modern, cross-platform technologies like .NET Core and Electron. Attack Surface Analyzer 2.0 now runs on Windows, Linux, and macOS and is available as an open source project on GitHub.

Attack Surface Analyzer 2.0 can help you identify potential security risks introduced by changes to an operating system’s security configuration by identifying changes in key areas, including:

  • File System
  • User Accounts
  • System Services
  • Network Ports (listeners)
  • System Certificate Stores
  • Windows Registry

This tool can play an important role in ensuring that the software you develop or deploy doesn’t adversely affect the operating system security configuration by allowing you to scan for specific types of changes.

Results from the comparison analysis feature highlight relevant changes, which can be easily viewed or exported.

The tool includes both Electron and command line interface options. Results for the command line use option are written to a local HTML or JSON file, making it easy to include as part of your automated toolchain.

Detecting these types of changes can be error prone and time consuming. Attack Surface Analyzer 2.0 helps make it easy.

We look forward to your comments, ideas, and contributions for improving this tool. To learn more about Attack Surface Analyzer 2.0, please visit our GitHub project page at

The post Announcing the all new Attack Surface Analyzer 2.0 appeared first on Microsoft Security.