A quick summary of Active Directory to get us started. Active Directory is a Microsoft product which runs several services on a Windows server to manage user permissions and access to networked resources. It stores data as objects – which can be users, groups, applications or devices. These are further defined as either resources – such as printers or computers, or security principals – such as users or groups.
From the above, you will understand just how important it is to secure your Active Directory properly. This can be done in a number of ways including hardening, auditing and detection rules.
The first step you should take is hardening your active directory against known attacks and following best practices. There are a lot of great articles out there to follow, starting with the official guide from Microsoft, found here. This contains important topics such as reducing the attack surface, audit policy recommendations and implementing least privilege administrative models.
Next up, activedirectorypro, which details 25 best practices to follow to secure your Active Directory. This contains tips on securing domain admins, local administrators, audit policies, monitoring AD for compromise, password policies, vulnerability scanning and much more.
Finally in terms of long read best practices articles, “The Ultimate Guide to Active Directory Best Practices” from DNSstuff. Like the previous two articles, this covers all important steps to secure your Active Directory.
Domain trusts are an important part of Active Directory security which most not be ignored. Here are some useful articles to understand domain trusts and ensure proper security processes are followed.
- Active Directory Trusts
- Top Ten Issues with Active Directory Trusts and Corporate Mergers
- Fundamentals of Active Directory Trust Relationships
Sven also mentions the importance of securely setting up domain trusts. Along with this, he mentions upgrading DC’s to at least 2016. See this article which details the process of upgrading your DC’s to 2016 along with understanding functional levels. Also see the second comment which details further tips to securely use and set up your domain controllers.
Even though Active Directory is the main focus, ensure you do not forget about any *nix systems connected to your active directories. Dependent on the connected systems, ensure they are also configured securely using best practices.
The main point I would like to concentrate on is securing privileged access. Incorrectly setup access is one of the main causes of issues and the article provided by Nathan is great to resolve these. Check the article regarding securing privileged access out here. Also don’t forget to checkout PingCastle and Bloodhound tools.
Once you believe you have followed the best practices and hardening, the next step is auditing your environment to see where your Active Directory is still vulnerable.
You should use tools such as BloodHound and PingCastle to audit your Active Directory environment.
Lets start with BloodHound, this article from ZephrFish details well what BloodHound is, what it is used for; and how to use it.
These tools will allow you to find the existing issues in your environment. Take these issues and go back to the start of this post and see the best practices guide to resolve them. Once you are happy that your Active Directory is set up securely, the next step is monitoring rules to detect when malicious actors are attempting to attack your environment.
Once your Active Directory environment has been set up securely and audited, the next step is setting up monitoring rules using a SIEM. To learn more about SIEM, check out my “Learn SIEM for free” article.
As always, there are a large amount of rules in the Sigma repository which we can use to monitor Active Directory. The rules can be found in this directory. Please check the log source > definition under each rule which details the audit / log requirements for each rule.
There were also a couple useful comments regarding detection rules.
UltimateWindowsSecurity have a fantastic list of Windows Security Event’s. They have lots of useful information around WSEL and examples which help you understand them better. Larry is also working on a list of rules which you can check out here.
Sysmon allows for a much more detailed monitoring of events and should always be deployed on domain controllers. See the guide from Microsoft here which explains what Sysmon is, what it can be used for and how to set it up. Once setup, Sysmon logs can be sent to a central SIEM for more accurate monitoring of events. The SIGMA repository above has some rules which require Sysmon. For a more in depth look into Sysmon, check out this guide from Varonis.
At this point you will now have your Active Directory set up securely, audited and well monitored. I hope you have found this article useful and learned something from it. I’d like to thank everyone again who replied to the thread with useful resources, points and articles of their own.
What Is Threat Modeling?
Threat modeling is a proactive approach to identifying entry points to enumerate threats and building security measures to prevent security breaches in applications and computer and network systems. It’s an engineering technique you can use to help you identify threats, attacks, vulnerabilities, and countermeasures that could affect your application and systems. You can use threat modeling to shape your application’s and system’s design and improve security.
Threat modeling provides a good foundation for the specification of security requirements during application development. When applied during the early phases of software development, threat modeling empowers developers in several ways. These range from verifying application architecture, identifying and evaluating threats, designing countermeasures, to penetration testing based on a threat model. There is however paucity of established techniques and tools for threat modeling and analysis.
What Most Threat Models Include
Due to the uniqueness in nature, most threat models do not look the same but generally include the following basics:
- A description of the threat
- A list of assumptions regarding the function of the software or organization that can be reviewed in the future
- Actions for each vulnerability
- How to review and verify the vulnerabilities are being watched and are secure
Why is threat modeling necessary?
As organizations become more digital and cloud-based, IT systems face increased risk and vulnerability. Growing use of mobile and Internet of Things (IoT) devices also expands the threat landscape. And while hacking and distributed-denial-of-service (DDoS) attacks repeatedly make headlines, threats can also come from within–from employees trying to steal or manipulate data, for example.
Smaller enterprises are not immune to attacks either–in fact they may be more at risk because they don’t have adequate cybersecurity measures in place. Malicious hackers and other bad actors make risk assessments of their own and look for easy targets.
Threat Modeling Methodologies
OCTAVE (Practice Focused)
The Operationally Critical Threat, Asset, and Vulnerability Evaluation methodology was one of the first created specifically for cybersecurity threat modeling. Developed at Carnegie Mellon University’s Software Engineering Institute (SEI) in collaboration with CERT, OCTAVE threat modeling methodology is heavy-weighted and focused on assessing organizational (non-technical) risks that may result from breached data assets.
Using this threat modeling methodology, an organization’s information assets are identified and the datasets they contain receive attributes based on the type of data stored. The intent is to eliminate confusion about the scope of a threat model and reduce excessive documentation for assets that are either poorly defined or are outside the purview of the project.
Though OCTAVE threat modeling provides a robust, asset-centric view, and organizational risk awareness, the documentation can become voluminous. OCTAVE lacks scalability – as technological systems add users, applications, and functionality, a manual process can quickly become unmanageable.
This method is most useful when creating a risk-aware corporate culture. The method is highly customizable to an organization’s specific security objectives and risk environment.
Trike Threat Modeling (Acceptable Risk Focused)
Trike threat modeling is a unique, open source threat modeling process focused on satisfying the security auditing process from a cyber risk management perspective. It provides a risk-based approach with unique implementation, and risk modeling process. The foundation of the Trike threat modeling methodology is a “requirements model.” The requirements model ensures the assigned level of risk for each asset is “acceptable” to the various stakeholders.
With the requirements model in place, the next step in Trike threat modeling is to create a data flow diagram (DFD). System engineers created data flow diagrams in the 1970s to communicate how a system moves, stores and manipulates data. Traditionally they contained only four elements: data stores, processes, data flows, and interactors.
The concept of trust boundaries was added in the early 2000s to adopt data flow diagrams to threat modeling. In the Trike threat modeling methodology, DFDs are used to illustrate data flow in an implementation model and the actions users can perform in within a system state.
The implementation model is then analyzed to produce a Trike threat model. As threats are enumerated, appropriate risk values are assigned to them from which the user then creates attack graphs. Users then assign mitigating controls as required to address prioritized threats and the associated risks. Finally, users develop a risk model from the completed threat model based on assets, roles, actions and threat exposure.
However, because Trike threat modeling requires a person to hold a view of the entire system to conduct an attack surface analysis, it can be challenging to scale to larger systems.
P.A.S.T.A. Threat Modeling (Attacker Focused)
The Process for Attack Simulation and Threat Analysis is a relatively new application threat modeling methodology. PASTA threat modeling provides a seven-step process for risk analysis which is platform insensitive. The goal of the PASTA methodology is to align business objectives with technical requirements while taking into account business impact analysis and compliance requirements. The output provides threat management, enumeration, and scoring.
The PASTA threat modeling methodology combines an attacker-centric perspective on potential threats with risk and impact analysis. The outputs are asset-centric. Also, the risk and business impact analysis of the method elevates threat modeling from a “software development only” exercise to a strategic business exercise by involving key decision makers in the process.
PASTA threat modeling works best for organizations that wish to align threat modeling with strategic objectives because it incorporates business impact analysis as an integral part of the process and expands cybersecurity responsibilities beyond the IT department.
This alignment can sometimes be a weakness of the PASTA threat modeling methodologies. Depending on the technological literacy of key stakeholders throughout the organization, adopting the PASTA methodology can require many additional hours of training and education.
STRIDE Threat Modeling (Developer Focused)
STRIDE stands for Spoofing Tampering Repudiation Information Message Disclosure Denial of Service and Elevation of Privilege. Microsoft’s threat modeling methodology – commonly referred to as STRIDE – aligns with their Trustworthy Computing directive of January 2002. The primary focus of that directive is to help ensure that Microsoft’s Windows software developers think about security during the design phase.
The STRIDE threat modeling goal is to get an application to meet the security properties of Confidentiality, Integrity, and Availability (CIA), along with Authorization, Authentication, and Non-Repudiation. Once the security subject matter experts construct the data flow diagram-based threat model, system engineers or other subject matter experts check the application against the STRIDE threat model classification scheme.
This methodology is both well documented and well known owing to Microsoft’s significant influence in the software industry and their offering of Microsoft TMT.
VAST Threat Modeling (Enterprise Focused)
The Visual, Agile, and Simple Threat modeling (VAST) methodology was conceived after reviewing the shortcomings and implementation challenges inherent in the other threat modeling methodologies. The founding principle is that, in order to be effective, threat modeling must scale across the infrastructure and entire DevOps portfolio, integrate seamlessly into an Agile environment and provide actionable, accurate, and consistent outputs for developers, security teams, and senior executives alike.
A fundamental difference of the VAST threat modeling methodology is its practical approach. Recognizing the security concerns of development teams are distinct from those of an infrastructure team, this methodology calls for two types of threat models.
Why you should Threat Model?
Threat Modeling gives a complete picture of the threats and possible attack paths. These attack paths can subsequently be used for instance to create efficient test scenarios, design adjustments or to define additional mitigating measures. Next to the result, the threat modeling workshop is a great way to raise security awareness and collaboration.
This allows you to execute concrete next steps in improving security.
While taking the use of the cloud, we always overlook the issue of security and assume the cloud provider will for sure handle that. However, it is important to understand the security responsibility does not solely lie with the cloud provider. Security is a shared responsibility when using the cloud.
Below I try to outline the different responsibilities in securing the cloud for each of the stakeholders
Designed to provide the highest degree of flexibility and management control to customers, IaaS services also place more security responsibilities on customers. Let’s use Amazon Elastic Compute Cloud (Amazon EC2) as an example.
When customers deploy an instance of Amazon EC2, the customer is the one who manages the guest operating system, any applications they install on these instances and the configuration of provided firewalls on these instances. They are also responsible for overseeing data, classifying assets, and implementing the proper permissions for identity and access management.
While IaaS customers retain a lot of control, they can lean on CSPs to manage security from a physical, infrastructure, network, and virtualization standpoint.
In PaaS, more of the heavy lifting is passed over to CSPs. While customers focus on deploying and managing applications (as well as managing data, assets, and permissions), CSPs take control of operating the underlying infrastructure, including guest operating systems.
From an efficiency standpoint, PaaS offers clear benefits. Without having to worry about patching or other updates to operating systems, security and IT teams recoup time that can be allocated to other pressing matters.
Of the three deployment options, SaaS places the most responsibility on the CSP. With the CSP managing the entire infrastructure as well as the applications, customers are only responsible for managing data, as well as user access/identity permissions. In other words, the service provider will manage and maintain the piece of software—customers just need to decide how they want to use it.