finding countermeasures for active directory threats using nist 800-30 frameworks

FINDING COUNTERMEASURES FOR ACTIVE DIRECTORY THREATS

USING NIST 800-30 FRAMEWORKS

By

Aldo Elam Majiah

2-2012-206

A thesis submitted to the Faculty of

ENGINEERING & INFORMATION TECHNOLOGY

in partial fulfillment of the requirements

for the

MASTER’S DEGREE

in

INFORMATION TECHNOLOGY

SWISS GERMAN UNIVERSITY

EduTown BSD City

Tangerang 15339

Indonesia

August 2014

Revision after the Thesis Defense on 25 August 2014

Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks of 161

Aldo Elam Majiah

STATEMENT BY THE AUTHOR

I hereby declare that this submission is my own work and to the best of my

knowledge, contains no material previously published or written by another person,

nor material which to a substantial extent has been accepted for the award of any

other degree or diploma at any educational institution, except where due

acknowledgement is made in the thesis.

Aldo Elam Majiah

_______________________________________ ________________

Student Date

Approved by:

Dr. Ir. Mohammad A. Amin Soetomo, M.Sc.

________________________________________ __________________

Thesis Advisor Date

Charles Lim, M.Sc.

________________________________________ __________________

Thesis Co-Advisor Date

Dr. Ir. Gembong Baskoro M. Sc.

______________________________________ _________________

Dean Date


Aldo Elam Majiah

ABSTRACT

FINDING COUNTERMEASURES FOR ACTIVE DIRECTORY THREATS USING

NIST 800-30 FRAMEWORKS

By

Aldo Elam Majiah

Dr. Ir. Mohammad A. Amin Soetomo, M.Sc., Advisor

Charles Lim, M.Sc, Co-Advisor

SWISS GERMAN UNIVERISTY

Bumi Serpong Damai

Data showed that many Active Directory (AD) implementations in the enterprises /

organizations are insecure. Since AD is ubiquitous and it is an essential part of a

security enterprise, security of AD is imperative. This research focuses on how to

secure an AD environment. It uses a risk assessment approach to find threats in

existing AD and then recommend countermeasures for these threats. A new AD risk

assessment is developed for the purpose of this research. Components of AD, where

the risk assessment is performed, are also defined. The results of the assessment are a

series of countermeasures for AD and a set of security-based GPO, both to be

implemented in the assessed AD environment. To ensure the effectiveness,

implementable level, and evaluation of the risk assessment results, demonstration of

the countermeasures and experts’ judgment are also conducted. The research

concludes that risk assessment approach for securing an AD environment is highly

implementable for securing an organization’s AD. Specific threats on an

organization’s AD environment and the recommended countermeasures are identified

in well-structured processes, which can be performed in accordance to the developed

framework.

Keywords: Active Directory, Countermeasure, Threat, Risk, Framework


Aldo Elam Majiah

© Copyright 2014

By Aldo Elam Majiah

All rights reserved


Aldo Elam Majiah

DEDICATION

I dedicate this thesis to my family; my wife Maya Patricia Siwy, my wonderful son

Castiel Elivair Majiah and his grandmother Haryati. Thank you for being my strength

throughout this entire master program.

I can do all this through him who gives me strength. (Philippians 4: 13).


Aldo Elam Majiah

ACKNOWLEDGMENTS

The author wishes to thank my advisors in Swiss German University, Dr. Ir.

Mohammad A. Amin Soetomo M.Sc. and Charles Lim, M.Sc, who were more than

generous with their expertise and precious time. Their guidance made the completion

of this research an enjoyable experience. Special thanks to Jusak Soehardja and his IT

team for letting me perform data collection in their organization.


Aldo Elam Majiah

Table of Contents

STATEMENT BY THE AUTHOR ........................................................................................... 2

ABSTRACT ............................................................................................................................... 3

DEDICATION ........................................................................................................................... 4

ACKNOWLEDGMENTS ......................................................................................................... 6

CHAPTER 1 - INTRODUCTION ........................................................................................... 13

1.1 Background ............................................................................................................... 13

1.2 General Statement of Problem Area.......................................................................... 13

1.3 Research problem ...................................................................................................... 14

1.4 Research objectives ................................................................................................... 15

1.5 Research questions .................................................................................................... 15

1.6 Significance of study ................................................................................................. 16

1.7 Scope and limitation .................................................................................................. 16

1.8 Thesis structure ......................................................................................................... 17

CHAPTER 2 - LITERATURE REVIEW ................................................................................ 19

2.1 Active Directory ........................................................................................................ 19

2.1.1 Active Directory as a directory service .............................................................. 19

2.1.2 Active Directory fundamentals .......................................................................... 20

2.1.3 Charateristic of Active Directory ....................................................................... 21

2.1.4 Related works on AD and network security ...................................................... 24

2.2 Risk frameworks ....................................................................................................... 30

2.2.1 Octave Allegro ................................................................................................... 30

2.2.2 FAIR .................................................................................................................. 31

2.2.3 RISK IT .............................................................................................................. 31

2.2.4 NIST SP 800-30 ................................................................................................. 32

2.2.5 NIST SP 800-30 Revision 1 ............................................................................... 35

2.2.6 AD risk framework ............................................................................................ 36

2.3 Threat and countermeasure ....................................................................................... 38

2.4 Expert judgment ........................................................................................................ 42

2.5 Design science ........................................................................................................... 42

2.6 Theoretical framework .............................................................................................. 46


Aldo Elam Majiah

CHAPTER 3 - RESEARCH METHODOLOGY .................................................................... 48

3.1 Steps of research methodology ................................................................................. 49

3.2 Key activities for design and development ............................................................... 49

3.2.1 AD system characterization ............................................................................... 49

3.2.2 Threat sources and events identification ............................................................ 53

3.2.3 Identification of vulnerability ............................................................................ 53

3.2.4 Determination of likelihood of occurence ......................................................... 54

3.2.5 Determination of impact magnitude .................................................................. 55

3.2.6 Risk determination ............................................................................................. 55

3.2.7 Countermeasure recommendation ..................................................................... 56

CHAPTER 4 – RISK ASESSMENT & ANALYSIS .............................................................. 57

4.1 Design and development (risk assessment) ............................................................... 57

4.1.1 AD system charaterization ................................................................................. 57

4.1.2 Threat sources and events identification ............................................................ 57

4.1.3 Identification of vulnerability ............................................................................ 59

4.1.4 Determination of risk level and countermeasure ............................................... 60

4.2 Demonstrate countermeasure (prototyping) .............................................................. 61

4.3 Evaluate (expert judgment) ....................................................................................... 77

4.4 Observation ............................................................................................................... 77

CHAPTER 5 – CONCLUSION .............................................................................................. 85

5.1 Conclusion ................................................................................................................. 85

5.2 Future works .............................................................................................................. 86

GLOSSARY ............................................................................................................................ 87

REFERENCES ........................................................................................................................ 90

APPENDIX .............................................................................................................................. 94

Appendix 1: AD Characterization Assessment (original forms) ......................................... 94

Appendix 2: AD Characterization Assessment (printed) ................................................... 102

Appendix 3: List of Threat Events and Description ........................................................... 108

Appendix 4: Vulnerability Identification Table ................................................................. 133

Appendix 5: Threat Risk-Level and Its Countermeasures ................................................. 141

Appendix 6: Expert’s Profiles ............................................................................................ 150

Appendix 7: Artifacts Evaluated by Experts ...................................................................... 152


Aldo Elam Majiah

Appendix 8: Experts’ Opinion ........................................................................................... 158

CURRICULLUM VITAE ..................................................................................................... 161


Aldo Elam Majiah

List of Figures

Figure 1: Fishbone diagram of weak AD security ................................................................... 15

Figure 2: Typical AD domain diagram (Robbie Allen, 2003) ................................................. 20

Figure 3: AD forest example (Robbie Allen, 2003) ................................................................ 20

Figure 4: AD logical and physical structures (Sakari Kouti, 2004) ......................................... 21

Figure 5: Components of AD (Sakari Kouti, 2004) ................................................................. 21

Figure 6: Building blocks of AD (Sakari Kouti, 2004) ........................................................... 22

Figure 7: Building blocks of AD (Brian Desmond, 2013) ....................................................... 22

Figure 8: Elements of AD (Rommel, 2008)............................................................................. 22

Figure 9: Major components of AD (Kocis, 2001) .................................................................. 23

Figure 10: Components of AD (Wilkins, 2001) ...................................................................... 23

Figure 11: Summary of AD components ................................................................................. 24

Figure 12: Threat and countermeasure relationship (Chadwick, 2005) ................................... 26

Figure 13: Detailed AD threat & countermeasures (Chadwick, 2005) .................................... 27

Figure 14: Countermeasures derived from technical measures and policy (Sandberg, 2013) . 27

Figure 15: Countermeasures needed to secure enterprise endpoints (Sandberg, 2013) .......... 28

Figure 16: Octave Allegro steps (Richard A. Caralli, 2007) ................................................... 30

Figure 17: Fair methodology ................................................................................................... 31

Figure 18: Risk IT Process Model (ISACA, 2009).................................................................. 32

Figure 19: Risk assessment activities (NIST, 2002) ................................................................ 34

Figure 20: Risk assessment processes (NIST, 2012) ............................................................... 35

Figure 21: Risk assessment steps (NIST, 2012) ...................................................................... 36

Figure 22: AD risk assessment framework .............................................................................. 37

Figure 23: Countermeasures technologies for preventing threats (Michael A. Davis, 2010).. 38

Figure 24: Technology and general security practices as countermeasures (Michael A. Davis,

2010) ........................................................................................................................................ 38

Figure 25: Security countermeasures model (Straub, 1986) .................................................... 39

Figure 26: Security countermeasures model (D'Arcy, 2007)................................................... 39

Figure 27: Threat & its agents (International Telecommunication Union, 2003) ................... 40

Figure 28: Threats point of view (Farahmand, 2004) .............................................................. 40

Figure 29: Relationship between security components (Lenaghan, 2007) .............................. 41

Figure 30: Design-science activities ........................................................................................ 43

Figure 31: Design processes .................................................................................................... 43

Figure 32: Design cycle in relation to mental activities .......................................................... 44

Figure 33: DSRP Model (Ken Peffers, 2006) .......................................................................... 46

Figure 34: Methodology and theoretical framework ............................................................... 47

Figure 35: AD components revolves around risk assessment framework .............................. 47

Figure 36: Thesis methodology ............................................................................................... 48

Figure 37: Distribution of key activities .................................................................................. 50

Figure 38: Distribution of threat events ................................................................................... 59

Figure 39: Vulnerability scan results ....................................................................................... 59

Figure 40: Summary of penetration testing report ................................................................... 60


Aldo Elam Majiah

Figure 41: Risk assessment result ............................................................................................ 61

Figure 42: AD for prototyping ................................................................................................. 62

Figure 43: Access files using alternative OS ........................................................................... 63

Figure 44: Offline password cracking using Ophcrack ........................................................... 63

Figure 45: raising functional levels .......................................................................................... 64

Figure 46: Primary and secondary DC ..................................................................................... 64

Figure 47: Successfully transferred RID master role ............................................................... 65

Figure 48: Computer-based OU deployment ........................................................................... 65

Figure 49: Reduce number of domain admins ......................................................................... 66

Figure 50: Configure an account ability to logon from only one host ..................................... 67

Figure 51: Fail pass-the-hash attack ........................................................................................ 67

Figure 52: Deploying restricted group ..................................................................................... 68

Figure 53: Using run as for administrative tasks ..................................................................... 68

Figure 54: Weak password policy............................................................................................ 69

Figure 55: Stronger password policy ....................................................................................... 69

Figure 56: Weak account lockout policy ................................................................................. 70

Figure 57: Password cracking using Medusa........................................................................... 70

Figure 58: Stronger account lockout policy ............................................................................. 71

Figure 59: Testing account lockout policy............................................................................... 71

Figure 60: Backup AD using Windows Server backup ........................................................... 72

Figure 61: WSUS configuration GPO ..................................................................................... 73

Figure 62: Successful exploit using Metasploit ....................................................................... 73

Figure 63: Fail exploit attempt ................................................................................................. 74

Figure 64: Nessus scan result ................................................................................................... 74

Figure 65: Cain and Abel sniffing FTP credential ................................................................... 76

Figure 66: Final AD risk assessment framework ..................................................................... 78

Figure 67: Final AD components ............................................................................................. 78

Figure 68: Risk assessment results (moderate risk level and up) ............................................ 79

Figure 69: Implementation of high risk GPO countermeasures .............................................. 80

Figure 70: Implementation of medium risk GPO countermeasures (1) ................................... 80




Aldo Elam Majiah

List of Tables

Table 1: Penetration testing activities data (IT Security Firm X, 2013) .................................. 14

Table 2: Strength and weakness of several risk assessment frameworks ................................ 36

Table 3: Design-science guidelines (Alan R. Hevner, 2004) ................................................... 45

Table 4: Table for likelihood of event initiation or occurrence (NIST, 2012) ........................ 54

Table 5: Table for likelihood of threat event resulting in impact (NIST, 2012) ...................... 54

Table 6: Table for determining/assessing overall likelihood (NIST, 2012) ............................ 54

Table 7: Table for assessing impact of threat events (NIST, 2012)......................................... 55

Table 8: Table for determining level risk as combination of likelihood and impact (NIST,

2012) ........................................................................................................................................ 55

Table 9: Table for describing level of risk assessment (NIST, 2012) ..................................... 56

Table 10: Threat sources taxonomy (NIST, 2012) .................................................................. 58

Table 11: Final countermeasures and their categories ............................................................. 82


Aldo Elam Majiah

CHAPTER 1 - INTRODUCTION

1.1 Background

Active Directory (AD) is Microsoft’s implementation of centralized management of users,

hosts, and other objects (Microsoft, 2006). AD is a logical structure that can holds objects

such as users and hosts. The shape of an AD look like a tree of folders, with the root of it

represents the name of the domain.

The size of an AD is varied much; a single AD may consist of from a few to thousands of

hosts and users. Since it is not easy to manage a few hundreds to thousands of users and

hosts, Microsoft creates AD directory service tools to centrally manage users, accounts,

servers, group policies, and services. The tools also function as the central authority for

network security. By centrally managing servers, systems administrators are able to maintain

users, hosts, and policies from a single central location, simplifying the process of host and

user management. A centralized system such as this needs a top of the line security since a

compromised AD means compromising the whole hosts and users therein.

Active Directory (AD) is the core component of the Windows server infrastructure. A well

designed and implemented Active Directory is the foundation of any optimized Windows

infrastructure. A correctly designed, configured and implemented Active Directory will

significantly reduce this risk. More and more companies are realizing that a properly secure

Active Directory is a critical component of a fully secured Windows network (Barnard,

2006). Hence the security of the AD is one of the most important things to be managed by

any enterprises. Microsoft itself realizes that Active Directory environment often becomes a

target to rapidly growing and evolving external attack (Microsoft, 2013).

1.2 General Statement of Problem Area

AD is considered to be a critical part of a network infrastructure, moreover, its ability to

mitigate internal threats is also considered crucial for increasing overall internal security of

the network (Tankard, 2012). With such importance, any enterprise should have their AD

secured properly. The tasks of securing AD are not easy as the administrative management is

complex and time consuming. According to a survey (Osterman Research, 2010), 42%

organizations deploys users in incorrect security groups or distribution list when using group

policy management, a well-known feature of AD. The research also found that managing

groups in AD is a complicated task and is requiring time investment. Furthermore, another

survey (InformationWeek Analytics, 2011) states that the biggest challenge in maintaining

information and network security in an organization is management of complexity. All in all,

AD management can be very complex and time consuming. And if it is not done properly, it

could impact security or business performance (Tankard, 2012).


Aldo Elam Majiah

The following data from an IT security consulting firm showed that AD could be

compromised almost in every cases of internal penetration testing. Table below shows

penetration testing activities during year 2011 to 2013 from an IT security firm. Some of

these penetration testing activities include internal black box pen-testing. In almost all

internal black box pen-testing activities, AD of the enterprises were compromised. Name of

the companies involved in pen-test activities were not disclosed, instead we are using

company type and numerical representation to identify the companies.

Table 1: Penetration testing activities data (IT Security Firm X, 2013)

Company type Pen-test activities AD domain level

How AD was compromised

Undisclosed data

These data were taken during year 2011 to 2013 from a security consulting firm in Jakarta

Indonesia. Although the data are small compared to the existing AD environment in the

whole region, it can serve as a basis of an argument that there are some apparent problems in

developing secure AD environment.

1.3 Research problem

Referring to penetration testing data from the company in the previous section, we can

deduce there are problems in implementing a secure AD. In almost all internal penetration

testing, save for one company, the enterprise’s AD is compromised. The method of

compromising AD is not always the same from company to company as stated in the last

column of the table.

Security risks can be reduced by taking action on three major components: people, process,

and technology (Janes, 2012). Taking these three accounts into AD security problem, the

author creates following fishbone diagram to identify root cause of the problem.


Aldo Elam Majiah

Figure 1: Fishbone diagram of weak AD security

Three major domains; people, process, and technologies, are contributing to a weak AD

security. Each domain consists of several causes. People domain seems to contribute more

compared to other domains. This is aligned with the notions that “people are the weakest link

in IT security” and that “IT security is only as secure as the weakest link” (Michael T.

Simpsons, 2011).

Technology as the causes of weak AD is a very interesting domain to be explored. A better

understanding in technological management of AD may help a lot in securing AD. The focus

of this research is on technological domain. The reasons that this thesis is focusing on

technology part instead of people and process domain are because technology are more static

in nature compared to people and process domains. In focusing on technology domain to

secure AD, the author hopes solution of the problem of weak AD can be applied to wider and

diverse environment.

The rest of the thesis will emphasize on finding various threats and countermeasures in AD.

The author chooses two main areas which are interrelated as the main focus of this research:

existence of various threats and lack of knowledge countermeasures implementation.

1.4 Research objectives

The main objective of this research is to find known and existing threats in AD and finding

proper countermeasures for these threats. Countermeasures are defined as an action taken to

counteract a danger or threat (Oxford University Press, 2010).

1.5 Research questions

Deriving from the research objectives, the research questions for the thesis are:

What are existing threats for Active Directory?


Aldo Elam Majiah

How to countermeasure for these threats?

In order to answer the research question, we first have to describe known, if not all, threats to

AD. Next, we need to assess an AD to find actual threats in that particular environment.

Threats for AD may come from weakness in operating system, applications, databases,

policies, or other related security issues. We need first to list all these threats, assess the

actual threats in an AD environment, and then recommend solutions of how to counter them.

For the purpose of finding threats in an AD environment, this research utilizes risk

assessment approach.

1.6 Significance of study

The study is significant for two reasons.

First, this research will provide a risk assessment approach for identifying threats and

developing countermeasure for AD. Although risk assessment is a well-known approach,

implementing its methodology for assessing security of AD environment has not been done

before. The author hopes this methodology can be re-used by other organizations as a

preferred methodology for assessing their AD environment.

There are other methodologies and approaches for finding threats in applications, one of the

most used is using threat modeling as described in (Shostack, 2014). This approach is quite

useful in times of designing and building applications, as it is implementable in every step of

SDLC. This method is, in fact, the method used by Microsoft itself for securing many

applications. But threat modelling approach is mainly useful during development of

applications as this method dissects applications and then tries to find all possible threats in

every entry points to the applications. This threat modeling method, even though very

powerful in finding threats to applications, mostly deals with low level application behaviors

in contrast to holistic AD environment implementation point-of-view as used in this research.

In AD, we are dealing with a set of applications (for example DNS, LDAP, DHCP, Kerberos,

etc.) that have been packed together into one big application. And it is the implementation of

this one big application in a particular environment that should be assessed.

Second, the study will address the issue of weak security implementation of AD. This can

help enterprises to understand what is required to secure their AD and Windows environment.

Since AD and Windows-based environment are ubiquitous, this research will help securing

wide and various environment areas.

1.7 Scope and limitation

The scope of the thesis will be focused on threats caused by technological aspects. The author

recognizes threats can occur due to problems in people and process domains, for example


Aldo Elam Majiah

lack of the administrator’s security skill may lead to weak security configuration or the fact

that missing IT security policy may be the cause of overall weak security in managing IT

infrastructure. But these domains are wide and may fall out of the scope this thesis. The thesis

will focused on threats from technology domain point of view, the author leaves discussions

of threats on other domains to future works.

Threats are changing in daily basis and have a tendency of increasing over time. Hence the

threats, and their countermeasures, discussed in this research are an ever increasing list. As

the time of this writing, Windows operating system has reached a server version of 2012 and

client version of Windows 8.1. The newest threats and countermeasures from these newer

operating systems may not be available or well-studied yet. Likewise, older threats that are

present in older AD environment may not be present in newer systems. This fact gives a

notion that threats and countermeasure presented in this research are not a complete list; but it

is designed as a search process in which threats (and countermeasures) can be added or

subtracted over time.

1.8 Thesis structure

The structure of the thesis begins with chapter 1 which describes research background,

problem area, research objectives and research questions, significance of study, and the scope

and limitation of the research.

Chapter 2 developed literature review for building theories and frameworks to be used in this

thesis. Chapter 2.1 discusses AD in general and generates six components of AD that will be

used in risk assessment process later on. Chapter 2.2 discusses several risk frameworks. In

this subchapter, an AD risk framework is introduced. The rest of chapter 2 describes threat

and countermeasure relationships, a basis for expert judgment process, and literature review

for design science methodologies. The result of this chapter is a theoretical framework to be

used in this research. The framework shows how to perform risk assessment on AD in order

to find out threats and recommend related countermeasures.

Chapter 3 includes the research methodology used in the research, which is derived from

DSRP model, a design science methodology discussed in previous chapter. In addition, key

activities in performing risk assessment on AD are also defined in this chapter. More than

sixty key activities are elaborated in this chapter. This chapter also includes matrices and

definitions for performing risk assessment process, description on how to calculate and

estimate likelihood, impact, and risk level are detailed in this chapter.

Chapter 4 begins with the actual risk assessment process. It starts with system

characterization and ends with recommended countermeasures for that particular AD being

assessed. More than two hundreds threat events that are related directly or indirectly to AD

are stated. The author conducts data gathering about AD system characterization and related

vulnerabilities found in the AD using several methods such as; interview with the


Aldo Elam Majiah

organization, penetration testing in the organization’s network, and vulnerability assessment.

All data from these activities are added to as input for vulnerability identification process.

Next, a series of risk assessment process such as determining likelihood, impact, and risk

level are performed. Countermeasures are then created and recommended against threat that

has risk level more than moderate (that is moderate, high, and very high). Risks level lower

than a low criterion was accepted. It is also worth noted that the risk assessment results were

based on the risk appetite and culture of an organization, and for this research it is assumed

that risk appetite and culture of the organization was integrated into the assessment.

In chapter 4, several countermeasures are also demonstrated to see if they are implementable

and effective against the threats in the prototyping phase. The prototyping is performed using

exact replica of AD being assessed but it is performed in a virtual environment, not in the real

production AD environment of the organization. The result of the prototyping phase is tested

countermeasures. Expert judgment was also conducted to evaluate AD risk assessment

frameworks, AD components, security GPO, and threat–countermeasure pairs. Security GPO

and threat-countermeasure pairs are the result from risk assessment process.


Aldo Elam Majiah

CHAPTER 2 - LITERATURE REVIEW

2.1 Active Directory

2.1.1 Active Directory as a directory service Active Directory is Microsoft’s implementation of directory service. Directory service

provides the means to hierarchically organize and manage information (Beth Sheresh, 2002).

It also provides a way to securely manage complex systems of interrelated information.

Several directory services are known, for example: X.500, LDAP, DNS, OpenLDAP, IBM

SecureWay, Sun iPlanet, eDirectory, and Active Directory. Active Directory will become the

focus of this thesis.

(Timothy A. Howes, 2003) divides directory service into the following categories:

Application-specific directories. Examples in this category include the IBM/Lotus

Notes, Microsoft Exchange directory, and sendmail message transfer agent (MTA).

Network operating system (NOS)–based directories. Examples in this category

include directories such as Novell's eDirectory, Microsoft's AD, Sun Microsystems' NIS,

and Banyan's StreetTalk directory.

Purpose-specific directories. These are directory services are specifically designed for a

purpose and are not extensible, for example: DNS and Switchboard directory.

General-purpose, standards-based directories. These are directories developed to

serve the needs of applications; for example LDAP and X.500-based directories.

There is also other kind of directory service; for example as the one shown in the research of

(Ihor Kuz, 2002). He proposes a wide-area management system using a directory service

which implements LDAP and DNS as the backbone of the system. Although still in the

research stage and some protocols have not yet been defined, this directory service is more

advanced as it integrates architecture for location-based worldwide resource management.

According to (Beth Sheresh, 2002), AD is one of technologically inventive network directory

service implementations. AD integrates Microsoft’s key directory service and network

technologies, such as LDAP and DNS. She also mentions that AD has four models:

Data model; AD is an information data store containing objects that represent network

resources, users, and a wide range of information.

Security model; AD is a Windows security infrastructure which uses ACL to protect

directory objects. It also employs multiple security technologies, such as using Kerberos

for authentication, SSL/PCT for encryption, and SAM for authentication with OS level.

Administration model; AD allows authorization of users to perform sets of actions on

objects or attributes within an OU. AD also provides delegation over directory tasks

Replication model; AD is comprised of replica system; this means changes made at any

replica are propagated to all directory information, and all replicas are consistent.


Aldo Elam Majiah

2.1.2 Active Directory fundamentals Data is stored within Active Directory in a hierarchical fashion similar to the way data is

stored in a file system (Robbie Allen, 2003). Each entry is referred to as an object and there

are two types of objects: containers and non-containers. The most common type of container

you will create in Active Directory is an Organizational Unit. AD domain diagram below

shows company domain mycorp.com has two OU called finance and sales. Sales OU has two

more OUs inside it, named Pre-sales and Post-Sales. And inside Pre-Sales OU there are

object such users, computers, and groups.

Figure 2: Typical AD domain diagram (Robbie Allen, 2003)

A domain can exist in a complex domain tree, called forest. This forest may consist of several

domains. Each of this domain can have hundreds or even thousands objects within it.

Figure 3: AD forest example (Robbie Allen, 2003)


Aldo Elam Majiah

2.1.3 Charateristic of Active Directory AD can also be viewed as having two, mostly independent, structures; logical and physical

(Sakari Kouti, 2004). The representation of domain diagram in figure 4 below is a physical

and logical view point of AD. The physical part consists of sites, replication, replicas,

partitions, domain controllers, and global catalog. The logical part consists of administrative

policy boundary, security policy boundary, and DNS namespace.

Figure 4: AD logical and physical structures (Sakari Kouti, 2004)

Figure 5: Components of AD (Sakari Kouti, 2004)

In addition (Sakari Kouti, 2004) also introduced the building block of AD as follows:

Domain Controllers, Domain, trust relationship, OU and other objects (user, computer, and

shared folder), groups, sites, replication, and global catalog. Furthermore, he also stated that

AD had a database of information which was represented as objects. These objects could be

in the form of user, group, computer, contact people, printers, shared folders, application

services, other resources, or configuration information.


Aldo Elam Majiah

Figure 6: Building blocks of AD (Sakari Kouti, 2004)

(Brian Desmond, 2013) describes the building blocks of AD were as follows: domain and

domain trees, forests, OU, global catalog, FSMO roles, domain and forest functional level,

and groups.

Figure 7: Building blocks of AD (Brian Desmond, 2013)

Similar to (Brian Desmond, 2013) and (Sakari Kouti, 2004), (Rommel, 2008) suggested the

following as the elements of AD: forest, domain tree, OU and leaf objects (such as computer

and user accounts), sites, and GPO.

Figure 8: Elements of AD (Rommel, 2008)

(Kocis, 2001) in his book listed major components of AD as follows: namespace, domain

tree, forest, domain, OU, and site. (Wilkins, 2001) described that AD could be viewed as

logical or physical components; the logical view was for the design aspect and the physical

view was the network components where Active Directory was executed. The logical

components included domains, trusts, trees, forests, containers, and organizational units. The

physical components included Domain controllers, subnets, and sites.


Aldo Elam Majiah

Figure 9: Major components of AD (Kocis, 2001)

Figure 10: Components of AD (Wilkins, 2001)

Diagram in figure shows the summary of all components of AD. The components are divided

into logical and physical. The logical components consist of DNS, forest design domain and

domain trees, trust relationship, groups, OU & leaf objects, administrative & security

boundary, FSMO roles, domain & forest functional level, and GPO. The physical

components consist of sites, subnets, DC, replication, global catalog & replicas.


Aldo Elam Majiah

Figure 11: Summary of AD components

For the purpose of this research, several components are re-grouped, resulting in six

components of AD. The groupings into six components are meant to ease in finding threats

which will be used later in risk assessment processes. These components are:

1. AD design and boundary; which consist of forest design, domain & domain & domain

trees, trust relationship.

2. AD management: groups, OU & leaf objects, administrative & security boundary,

FSMO roles, domain & forest functional level.

3. Policy implementation which is related to GPO implementation in AD.

4. Security of AD computer members.

5. Security of network.

6. Security of DC.

2.1.4 Related works on AD and network security Microsoft, as the creator of AD, uses four interrelated strategies to protect AD (Microsoft,

2013). These four strategies are: identifying vulnerabilities, reducing AD attack surface,

monitoring signs of compromise, and developing long-term security plan. Each strategy can

be detailed into several security processes as follows:

1. Identifying vulnerabilities:

Protect and update software

Fix faulty configuration, for example by:

Securing privileged accounts and groups.


Aldo Elam Majiah

Avoiding disabled security features on users’ workstations.

Avoiding granting excessive rights and permissions (for example to service

accounts).

Avoiding the use of identical local credentials across systems.

Avoiding installation of unauthorized applications and utilities.

Eliminating and controlling membership in highly privileged groups.

Eliminating unnecessary applications, Internet contents, and freeware on DC.

2. Reducing AD attack surface:

Managing privileged accounts and security groups.

Leveraging security built-in features.

Utilizing threat reducing tactics, such as: ensuring DC physical security, securing

admin workstations, using access control.

3. Monitoring for signs of compromise:

Implementing audit policies and detailing objects and systems to audit.

Monitoring events to help detecting compromise attempts.

4. Developing a long-term security plan:

Identifying, segregating, and securing critical users, applications, and systems.

Replacing legacy applications and systems with newer solutions.

Developing comprehensive protection strategies, such as:

Isolating legacy systems and applications.

Implementing controls that can be easily followed by users.

Utilizing security best practices for AD.

Ensuring applications and OS are up to date by implementing a patch

management.

Microsoft states for creating a secure AD, four strategies are needed: identifying

vulnerabilities, reducing AD attack surface, monitoring signs of compromise, and developing

long-term security plan. These strategies are in fact best practices and countermeasures for

securing AD.

Next research related to AD was conducted by researchers from University of Salford,

England. The research analyses threats in AD using STRIDE classification methodology

(Chadwick, 2005). The research limits its scope to AD that also holds roles as Web server

and has no trust to other domains.

Since it is based on Microsoft’s STRIDE framework, the research concludes that each threat

category in the framework also exists in AD. Those threats are: spoofing, tampering,

repudiation, information disclosure, denial of service, and elevation of privilege. The paper

also describes common countermeasures for each threat. Unfortunately, the paper does not


Aldo Elam Majiah

describe any real example of the threats. There is not any example of how to perform, for

example, a denial of service. The paper does not disclose how the attack could be performed,

or tools needed to do it. It is a theoretical paper discussing theoretical threats. In his paper,

(Chadwick, 2005) created suggested countermeasures come from knowing the threats. Each

threat can be countered by applying several countermeasures, and same countermeasure can

be applied to thwart several threats as shown in figure 12.

Figure 12: Threat and countermeasure relationship (Chadwick, 2005)

Another disadvantage of this research is that the framework used (STRIDE) provides a broad

categorization of the threats. For example let us take a look at denial of service threat; one

can ask the following questions relating to this threat: which service is to be denied? Which

vulnerability involved in the DoS? Etc. There could be many types of DoS threats in an AD,

is the countermeasure good enough to handle all of these DoS threats? This signifies that it is

not enough to treat threats as major categorization as shown by STRIDE. It is certainly

helpful to have a detail explanation of the threat.

Figure 13 shows the contribution of this paper’s research. Red boxes are threats and green

boxes are countermeasures. The arrows in the figures are all one way arrows, pointing from

threats to countermeasures. It indicates which threats can be mitigated with which

countermeasures. A threat may have more than one arrow, indicating a threat may need

several countermeasures.


Aldo Elam Majiah

Figure 13: Detailed AD threat & countermeasures (Chadwick, 2005)

(Sandberg, 2013)’s research was related to security of endpoint in the enterprise. The

conclusion of this thesis states that there are protecting enterprise endpoints needs a

combination of technical measures and policy.

Figure 14: Countermeasures derived from technical measures and policy (Sandberg, 2013)


Aldo Elam Majiah

There are four minimal set of technical measurement for securing enterprise’s endpoint:

inventory of hardware and software, patch management, security configuration management,

and mobile device management. However, to build a good security several additional

measures are needed, such as: better mobile device management, an anti-virus product,

service for helping users with new endpoints, and software whitelisting tool.

A good security policy is also needed to secure enterprise endpoints. The policy should

include: motivation for securing endpoints, technical measures employed, affected users’

privacy, expectations from the users, and pointers to other documentations.

Figure 15: Countermeasures needed to secure enterprise endpoints (Sandberg, 2013)

Research from (Bertino Bruschi, 2005) discusses existence of threat in Microsoft SQL server,

a server commonly found in Windows infrastructure. It focuses on security threats that can

arise against an SQL server when included in Web application environments. The paper

identifies three entry point of attack for SQL server: as web application (client side), network,

and SQL server port. Another research from (Eichstädt, 2005) which is still related to threats

in Windows environment, presents threat model attack points structured in accordance to web

services architecture. It states several attacks points for this particular type of server: external

attacker, web service, ASP net gate, internal attacker, unmanaged code, and application. The

two research shows there are many attack points on Windows related infrastructures.

Several researches describe the importance of attack chaining in the network. (Ammann,

2000) addresses vulnerabilities due to the configuration of various hosts in a network. They

then create a modeling approach to be used to analyze overall security of a network based.

The model is based on the interactions of vulnerabilities within a single host and within a

network of hosts, hence introduced chained exploitation. A research paper from (Hale, 2004)

presents a framework for chained exploitation attack analysis; the framework is comprised of

modeling for network elements, system vulnerabilities and attacker capabilities. The research

Technical measure

•inventory of hardware and software

•patch management

•security configuration management

•mobile device management

•anti-virus

•service for new users

•software whitelisting tool

Policy

•motivation for securing endpoints

•technical measures employed

•affected users' privacy

•users' expectations

•pointers to other documentations


Aldo Elam Majiah

integrates the framework into iterative process supporting automated vulnerability analysis by

enumerating vulnerability interactions and then presents it in a chaining tree presentation.

(Paul Ammann, 2005)’s research is somewhat more advanced from Hale’s. He provides an

alternative approach to (Hale, 2004) research by utilizing maximal level of penetration

possible on a host. Paul argues that chaining tree presentation often becomes unmanageable

because they are exponentially growing as the size of the network grows. Instead, it is better

to look for specific degrees of compromise on host, and focusing on that level of

compromise.

Other researches show how to countermeasure network related threats. (Asha. N, 2012)

studies different forms of SQL injection and proposes countermeasures for SQL injection

attack that is independent of platform and database. (Manadhata, 2011) introduces the use of

attack surface measurement as an indicator of the system’s security. They argue that the

smaller the attack surface, the more secure the system. And for Windows related

infrastructure, there are three methods of determining the attack surface: determining

Windows’ attack vectors (for example: features, services, ports, and dynamic web pages),

assigning weights to reflect their attack enablement, and estimating weighted counts of the

attack vectors.

Still related to securing a system, NIST publish a standard that can be used to secure servers

(NIST, 2008). The standard describes in details on how to secure servers’ operating system,

secure software or application installed in the server, and maintain secure configuration (for

example through patches and upgrades, backup, or server monitoring). Australia’s Defence

Signal Directorate even publishes a standard for mitigating cyber intrusion for Microsoft

Windows servers (The Defence Signals Directorate Australia, 2012). The standard defines

top mitigations for Microsoft servers as: application whitelisting, patch and deploy current

OS and applications, and restrict administrative privileges.

Availability as a security component is also discussed several papers. One of them is (Huang,

2004), which strengthens security using hardware redundancy in an implementation of DNS.

The concept of the paper is creating two integrated clusters of DNS servers that constantly

rotates individual servers’ role, handles failures of one server gracefully, and confines the

damages of successful intrusion to a limited time. Hence increasing availability as well as

mitigating attacks in the same time. Another paper from (Yih Huang, 2006) defines similar

concept for mitigating attack on Windows servers, that is by periodically cleansed the server

into a known clean state. Although the concept of increasing availability and mitigating

attack in the same time are viable, it is not compatible yet with all types of computing

systems.


Aldo Elam Majiah

2.2 Risk frameworks

In this research, the author uses risk assessment approach to determine threat and

countermeasure in AD. The following are several risk assessment frameworks evaluated for

the purpose of finding a suitable mixture of risk assessment framework for evaluating AD.

2.2.1 Octave Allegro

OCTAVE is a collection of tools, techniques, and methods for risk based information security

assessments. This framework was developed by the Software Engineering Institute (SEI) of

Carnegie Mellon through its CERT program. OCTAVE came in several flavors; OCTAVE,

OCTAVE-S, and OCTAVE Allegro. OCTAVE Allegro is a methodology to streamline and

optimize the process of assessing information security risks so that an organization can obtain

sufficient results with a small investment in time, people, and other limited resources

(Richard A. Caralli, 2007).

Octave Allegro has the following steps of methodology:

1. Establish Risk Measurement Criteria. It is a process to establish the organizational

drivers that will be used to evaluate the effects of a risk to an organization’s mission

and business objectives.

2. Develop an Information Asset Profile. This is the process of creating a profile for on the

information assets of the organization.

3. Identify Information Asset Containers which describe the places where information

assets are stored, transported, and processed.

4. Identify Areas of Concern. This is a risk identification process by brainstorming about

possible conditions or situations that can threaten an organization’s information asset.

5. Identify Threat Scenarios; examining a broad range of additional threats.

6. Identify Risks: capturing various consequences of risk.

7. Analyze Risks: computing a simple quantitative measure of the extent to which the

organization is impacted by a threat.

8. Select Mitigation Approach; determining which of the identified risks require

mitigation and develop a mitigation strategy for those risks.

Figure 16: Octave Allegro steps (Richard A. Caralli, 2007)


Aldo Elam Majiah

2.2.2 FAIR FAIR is a risk methodology which uses a taxonomy for breaking risk into sub-components

and then calculating an overall loss exposure profile based on calibrated data inputs. FAIR is

more of a high-level framework and is more conceptual when compared with the OCTAVE-

Allegro framework (Mark RM Talabis, 2013).

There are four FAIR stages:

1. Identify scenario components, which consist of two activities: identifying scenario

components and identifying the threat community.

2. Evaluate loss event frequency, which consist of five activities.

3. Evaluate probable loss magnitude, which consist of two activities; estimating worse

case scenarios and estimate probable loss magnitude.

4. Derive and articulate risk, plotting the loss event frequency and the probable loss

magnitude.

Figure 17: Fair methodology

2.2.3 RISK IT Risk IT is a risk framework developed by ISACA, a leading global provider of knowledge,

community, advocacy, certifications and education on information systems security

assurance, IT-related risk compliance, and IT enterprise governance.

The Risk IT Framework describes a detailed process model for the management of IT-related

risk. In this model, multiple references are made to risk analysis, risk profile, responsibilities,

key risk indicators and many other risk-related terms (ISACA, 2009).


Aldo Elam Majiah

The model of Risk IT is very detailed, it comprises of three models of risk evolving around

business objectives. The model consists of:

1. Risk governance: it is the process of ensuring that risk management practices are

embedded in the enterprise, enabling the enterprise to secure optimal risk-adjusted

return.

2. Risk evaluation: ensuring that IT-related risks and opportunities are identified, analysed

and presented in business terms.

3. Risk response: a process of ensuring that IT-related risk issues, opportunities are

addressed in line with business priorities and in a cost-effective manner.

Figure 18: Risk IT Process Model (ISACA, 2009)

For the risk evaluation part, ISACA defines the following activities:

1. Collect data: this is an activity to establish a model for data collection, collect data on

risk events, and identify risk factors.

2. Analyze risk: defining IT risk analysis scope and estimating IT risk, identifying risk

response options, and then performing a peer review of IT risk.

3. Maintain risk profile: map IT resources to business processes, determine business

criticallity of IT resources, understand IT capabilities, update IT risk scenario

components, maintain IT risk register and IT risk map, and develop IT risk indicators

2.2.4 NIST SP 800-30 NIST SP 800-30 defines risk management into three processes: risk assessment, risk

mitigation, and evaluation and assessment (NIST, 2002). For the risk assessment

methodology, NIST divided the assessment into 9 activities:


Aldo Elam Majiah

1. System Characterization. Identifying the boundaries of the IT system, along with the

resources and the information that constitute the system. Data gathering techniques that

can be used for this activity are: questionnaire, on-site interviews, document review,

and use of automated vulnerability scanning tools. Vulnerability scan includes a

mapping of the network and systems, identification of the services, and the creation of a

catalogue of vulnerable systems (Konstantinos Xynos, 2010). It is different than

penetration testing which has additional steps such as the exploitation of vulnerabilities

to confirm existence and determine damage if the vulnerability is exploited.

2. Threat Identification. Identifying the potential for a particular threat-source to

successfully exercise a particular vulnerability.

3. Vulnerability Identification. Analysing vulnerabilities related with the system

environment.

4. Control Analysis. Analysing implemented controls or controls that are planned for

implementation to minimize or eliminate the likelihood of a threat.

5. Likelihood Determination. Deriving an overall likelihood value indicating the

probability of a vulnerability may be exercised within the threat environment.

6. Impact Analysis. Measuring level of risk is to determine the adverse impact resulting

from a successful threat exercise of a vulnerability.

7. Risk Determination. Assessing the level of risk to the IT system.

8. Control Recommendations. Identifying and providing controls that could mitigate or

eliminate the identified risks.

9. Results Documentation. Documenting the result in an official report or briefing.


Aldo Elam Majiah

Figure 19: Risk assessment activities (NIST, 2002)


Aldo Elam Majiah

2.2.5 NIST SP 800-30 Revision 1 Revision 1 of NIST SP 800-30 (NIST, 2012) defines risk management processes as four

steps. Risk assessment is part of this processes. The risk management processes are: framing

risk, assessing risk, responding to risk, and monitoring risk. The diagram of the processes are

shown in the following figure 20:

Figure 20: Risk assessment processes (NIST, 2012)

The standards defines the risk assessment processes into four steps, prepare for the

assessment, conduct the assessment, communicate assessment results, maintain the

assessment. What we are interested most is the steps of conducting risk assessment, (NIST,

2012) defines five steps in conducting risk assessment. Depending on the purpose of the risk

assessment, organizations may find reordering these tasks advantageous.

1. Identify threat sources and events produced by those sources.

2. Identify vulnerabilities within organizations that could be exploited by threat sources

through specific threat events and conditions that could affect successful exploitation.

3. Determine the likelihood of how threat sources would initiate threat events and the

likelihood that these threats would be successful.

4. Determine the impacts from the exploitation of vulnerabilities by threat sources.

5. Determine risks as a combination of likelihood of threat exploitation and the impact of

such exploitation.


Aldo Elam Majiah

Figure 21: Risk assessment steps (NIST, 2012)

2.2.6 AD risk framework The following is strength and weakness of each discussed framework, presented in table 2.

Table 2: Strength and weakness of several risk assessment frameworks

Framework name Strength Weakness Octave Allegro This framework provides details worksheets

(for example worksheet for impact criteria) and questionnaires.

Compare to other framework, Octave Allegro is very complex. The threat catalogs for this framework are not provided. In contrast, NIST 800-30 SP1 has a very detailed threat catalogs.

FAIR Suitable for organizations that already have established metrics in determining likelihood or impact.

FAIR uses terminologies, approaches, and matrices that are not aligned with other frameworks. It may take some time to adjust to FAIR framework. This framework is also difficult to implement in organizations that does not have prior risk assessment.

RISK IT The framework viewed risk assessment as a cycling process to be implemented in an organization. Well suited for a mature organization.

Implementation processes need a significant amount or resources that span the entire organization. This framework cannot be completed in a short time due to its complexity.

NIST 800-30 This framework is open-ended and can be interpreted with a lot of flexibility by risk assessors. Furthermore, input and output for each activity are defined clearly.

Matrices provided in the example are high level and subjective. Implementation examples (worksheet, questionnaires) are not provided with a lot of details.

NIST 800-30 Revision 1 This framework is suitable for assessing technology related risks. As revision for NIST 800-30, this framework provides a lot of details (worksheet, threat catalogs, calculation of impact or likelihood) compare to its predecessor.

The methodologies for conducting risk assessment are now streamlined compare to NIST 800-30. Process such as characterizing the system to be assessed and recommending countermeasures are not integrated into risk assessment but part of other processes. System characterization is now part of risk preparation and countermeasure recommendation is part of maintaining risk.


Aldo Elam Majiah

NIST 800-30 and its revision 1 counterpart are known to be very well suited to be used in

assessing a system. NIST 800-30 framework is very popular and heavily adopted not only by

federal agencies but also local government. The framework is also useful to be used in a

highly diverse environment such as AD. Moreover, inputs and outputs for each of the steps

are clearly identified. (Mark RM Talabis, 2013). For those reasons, the author chooses to

implement a hybrid risk assessment approach for assessing AD. The risk assessment

framework is taken from NIST 800-30 Rev.1 and NIST 800-30.

To better understand AD system, the author takes the first step of risk assessment process

from NIST 800-30, AD system characterization, and places it as the first step. Risk

assessment framework steps from NIST 800-30 Rev. 1 are taken completely as subsequent

steps. As shown in figure 21, these steps are identifying threat sources and events, identifying

vulnerabilities, determining likelihood, determining impact, and determining risk. Last, the

author comes back to take a step from NIST 800-30, control recommendation, and places it

as the last step of the risk assessment framework. This last step is necessary to answer for one

the research questions. Hence for this research, the following AD risk assessment framework

is used (as shown in figure 22):

1. AD system characterization.

2. Threat sources and events identification.

3. Identification of vulnerability.

4. Determination of likelihood of occurrence.

5. Determination of impact magnitude.

6. Risk determination.

7. Countermeasure recommendation.

Figure 22: AD risk assessment framework

The framework is derived from NIST 800-30 and NIST 800-30 revision 1 as these two

related frameworks are suitable for technology/system related risk assessment such as AD.

Step two (threat sources and events identification) to six (risk determination) follows steps

from NIST 800-30 revision 1. The first step (AD system characterization) and the last step

(countermeasure recommendation) are added from NIST 800-30. Activities 2 to 6 which are

AD system characterization

Threat sources and events

identification

Identification of vulnerability

Determination of likelihood of occurrence

Determination of impact magnitude

Risk determination Countermeasure recommendation


Aldo Elam Majiah

taken from NIST 800-30 revision 1 are quite detailed but not enough for performing risk

assessment because it misses prior and subsequent process. Following NIST 800-30 Revision

1 completely is also not a good option since it can prove overwhelming due to complexity of

the tasks at hand. For this reason, the author borrows prior process (system characterization)

and subsequent process (countermeasure recommendation) from NIST 800-30, thus creating

a complete yet simplistic, risk assessment framework suitable for assessing AD.

2.3 Threat and countermeasure

In his book (Michael A. Davis, 2010) states there are several technologies for preventing

threats. These technologies are: antivirus, host protection system that includes personal

firewall and pop-up blockers, host-based intrusion prevention (both behavioral or signature

based), rootkit detection, and general security practices (end-user education, defense in depth,

system hardening, automatic updates, and have security in-mind from the beginning).

Figure 23: Countermeasures technologies for preventing threats (Michael A. Davis, 2010)

In essence (Michael A. Davis, 2010) states for preventing threats, one need to apply both

technological countermeasures and general security practices. The countermeasures will then

be able to prevent known threats.

Figure 24: Technology and general security practices as countermeasures (Michael A. Davis,

2010)

Antivirus

•personal firewall and pop-up blockers Host protection system

•signature-based or behavioural-based Host-based intrusion prevention

Rootkit detection

•end-user education, defense in depth, system hardening, automatic updates, security in-mind

General security practices


Aldo Elam Majiah

Straub defines security countermeasures consist of deterrent and preventative controls

(Straub, 1990). Deterrents include passive and active controls. Example of passive controls

are security policy, and security awareness programs, or other information designed to deter

mischief attempts by providing information regarding correct / incorrect usage of information

systems and punishment for incorrect usage. Examples of active deterrents are audits of IT

assets, and monitoring of employee activities. The primary purpose of both active and passive

deterrents is to discourage potential offenders by the threat of getting caught and punished for

any violation.

Likewise, Straub states that preventative controls are security measures designed to prevent

any attempted IT violation and digital crime by blocking access to the information system or

inhibiting use of certain information system functions (Straub, 1986). Examples of

preventative controls are applications that employ access control methods such as passwords.

Figure 25: Security countermeasures model (Straub, 1986)

D’Arcy, on the other hand, conceptualizes security countermeasures as security policies,

security awareness programs, monitoring practices, and preventative security software

(D'Arcy, 2007). His model is derived on the basis that individuals are not fully aware of the

existence of these security countermeasures within their organizations.

Figure 26: Security countermeasures model (D'Arcy, 2007)


Aldo Elam Majiah

According to (International Telecommunication Union, 2003), a threat is a potential violation

of security, and it can be active or passive. Impersonating an authorized entity is an example

of active threats and eavesdropping to steal a clear password is an example of a passive

threat. Threats have agents; these agents are people or organizations that are able to use the

threats: hackers, terrorists, vandals, organized crime, state sponsored, or insiders of an

organization.

Figure 27: Threat & its agents (International Telecommunication Union, 2003)

According to a survey in 2006 (L. A. Gordon, 2006), four top categories of threats that

accounted for nearly 74.3% of the total losses were: viruses, unauthorised access, laptop or

mobile hardware theft, and theft of proprietary information.

A thesis dissertation from (Farahmand, 2004) describes that threats can be seen from two

points of view: threat agents and penetration techniques. From threat agent point of view,

threat can be manifested by: environmental factors, authorized users, and unauthorized users.

While from penetration techniques point of view, threats are caused by: physical, personnel,

hardware, software, and procedural.

Figure 28: Threats point of view (Farahmand, 2004)

Threats

•Active

•Passive

Threat agents:

•hackers

•terrorists

•vandals

•organized crime

•state sponsored

•insiders of an organization

two threats points of view:

threat agents

environmental

factors authorized

unautihorized

penetration techniques

physical personnel hardware software procedural


Aldo Elam Majiah

There are several works defining relationship between threats and countermeasures. One of

them is the work from Onwubiko et al. (Lenaghan, 2007), they represent the relationship

between threats, countermeasures, and other security components as shown in the following

figure.

Figure 29: Relationship between security components (Lenaghan, 2007)

As seen in the figure 29, countermeasures are for mitigating threats, vulnerabilities, and risks.

And it is up to the owner of the system to impose countermeasures.

(Lenaghan, 2007) defines relationship between threat, countermeasures, and other

parameters. Threat agents give rise to threats, threats exploit vulnerabilities, and the

existences of countermeasures are to mitigate both threats and vulnerabilities.

Another relationship between threats, vulnerabilities, and countermeasures are defined by

Common Criteria. According to Common Criteria, it is assumed threat agents will actively

seek to exploit opportunities to violate security policies both for illicit gains and for well

intentioned, but nonetheless insecure actions. Threat agents may also accidentally trigger

security vulnerabilities, causing harm to the organisation (Common Criteria for Information

Technology Security Evaluation, 2012). Vulnerabilities should be: eliminated, minimized, or

monitored.

Common Criteria also states that threats to security and organisational security policy

commitments should be clearly articulated and the proposed security countermeasures be

demonstrably sufficient. Security countermeasures should be adopted that reduce: the

likelihood of vulnerabilities, the ability to exercise (i.e. intentionally exploit or

unintentionally trigger) a vulnerability, and the extent of the damage that could occur from a

vulnerability being exercised.


Aldo Elam Majiah

2.4 Expert judgment

Expert judgment is the use of structured and unstructured inputs from different individuals

who have specialist knowledge of a particular domain. This method of evaluation is used in

various fields such as problem structuring, model bounding, model structuring, and model

quantification.

This method relies on experts for evaluation. This brings up question the definition of expert.

According to Meyer and Broker, expert is a person who has a background in the subject

matter at the desired level of detail and who is recognised by his/her peers or those

conducting the study as being qualified to solve the questions (Mary A. Meyer, 2001). Ferrel

defines expert as a person with substantive knowledge about the events whose uncertainty is

to be addressed (Ferrell, 1994). O’Hagan states “a simple conception is that an expert is

someone who has great knowledge of the subject matter. However, expertise also involves

how the person organises and uses that knowledge” (O’Hagan, 2006).

Most studies in IT stream had to explicitly or implicitly rely on domain experts to evaluate

similarities or differences among various technologies (Chia-jung Tsui, 2010). The same

paper also describes several drawbacks of using expert validation techniques; it states that

although experts may be skillful in detecting the subtleties within and across the different

types of technologies, expert evaluation is often:

(1) Biased towards the views of specific experts contributing to specific studies,

(2) Static in the time of such evaluations, and

(3) Difficult to scale up to examine the relationships among a large number of ITs.

2.5 Design science

The methodology for this research will be taken from design science research point of view.

This subchapter deals with the basic of design science and the reason for selecting DSRP as

the methodology for this thesis.

(Salvatore T. March, 1995) defined there are two kinds of scientific interest in IT, descriptive

and prescriptive. Descriptive research aims at understanding the nature of IT. It is a

knowledge-producing activity corresponding to natural science. Prescriptive research aims at

improving IT performance. It is a knowledge-using activity corresponding to design science.

Hence March defined two kinds of science; natural science and design science. Natural

science is concerned with explaining how and why things are. Design science is concerned

with "devising artifacts to attain goals". Natural science explanations of how or why an

artifact works may lag years behind the application of the artifact. In medicine, for example,

the explanation of why a drug is effective in combating a disease may not be known until

long after the drug is in common use.

Still according to (Salvatore T. March, 1995), design science products are of four types,

constructs, models, methods, and implementations. And also, rather than posing theories,


Aldo Elam Majiah

design scientists strive to create models, methods, and implementations that are innovative

and valuable.

Design science consists of two basic activities, build and evaluate (Salvatore T. March,

1995). Building is the process of constructing an artifact for a specific purpose; build also

refers to the construction of the artifact, demonstrating that such an artifact can be

constructed. Evaluation is the process of determining how well the artifact performs and

refers to the development of criteria and the assessment of artifact performance against those

criteria. The constructed artifact itself presents a challenge to explain how and why it works.

Figure 30: Design-science activities

Next, we explore literature review by taking a look at a cognitive model of design processes

as describe by (Hideaki Takeda, 1990). Their work examined a design process from a

problem-solving point of view, and they formulated a model for a design process. This model

is constructed from unit design cycles. The design cycle consists of five sub processes as

shown in the diagram below:

Figure 31: Design processes

Explanations for above process are as follows:

1. Awareness of the problem: to pick up a problem by comparing the object under

consideration with the specifications, enumeration of problems, and decide on a

problem to be solved;

Build Evaluate

Awareness Suggestion Development Evaluation Conclusion


Aldo Elam Majiah

2. Suggestion: to suggest key concepts needed to solve the problem;

3. Development: to construct candidates for the problem from the key concepts using

various types of design knowledge;

4. Evaluation: to evaluate candidates in various ways, such as structural computation,

simulation of behavior, and cost evaluation. This evaluation confirm the solution;

5. Conclusion: to decide which candidate to adopt, modifying the descriptions of the

object. It concludes on a solution to be adopted and decide on action to be done next.

In order to elaborate the process of design in a clearer way and closer to real-world situation,

(Hideaki Takeda, 1990) distinguished two levels in the design process when they considered

the designer’s mental activity. One is the object level, where the designer thinks about design

objects themselves, for example, what properties the design object has and how it behaves in

a certain condition. The other is the action level, where the designer thinks about how to

proceed with his (her) design, that is, what s/he should do next. Next figure shows the two

mental activities (object and action) in relation to a design process cycle.

Figure 32: Design cycle in relation to mental activities


Aldo Elam Majiah

We can see that process that relates Development Evaluation is a cycle. This process is

aligned with design process called “Build and Evaluate” as described by design science

(Salvatore T. March, 1995). Hence this “Build and Evaluate” cycle can be achieved by

utilizing IT artifacts.

(Walls, 1992) defines design as both process (a set of activities) and a product (artifact).

While (Salvatore T. March, 1995) elaborates the processes as build and evaluate, and the

artifacts as constructs, models, methods, and instantiations.

Aligned with March and Takeda, (Alan R. Hevner, 2004) shows that in design science,

knowledge and understanding of a problem domain and its solution are achieved in the

building and application of the designed artifact. However, designing useful artifacts is

complex due to the need for creative advances in domain areas in which existing theory is

often insufficient. Hence, they described a conceptual framework and clear guidelines for

understanding, executing, and evaluating design science research. The guidelines for creating

IT artifacts are as follows (Alan R. Hevner, 2004):

Table 3: Design-science guidelines (Alan R. Hevner, 2004)

Design-Science Research Guidelines

Guideline Description Guideline 1: Design as an artifact Design-science research must provide a viable artifact in the form of

construct, a model, a method, or an instantiation.

Guideline 2: Problem relevance The objective of design-science research is to develop technology-based solutions to important and relevant business problems.

Guideline 3: Design evaluation The utility, quality, and efficacy of a design artifact must be rigorously demonstrated via well-educated evaluation methods.

Guideline 4: Research contributions

Effective design-science research must provide clear and verifiable contributions in the areas of the design artifact, design foundation, and / or design methodologies.

Guideline 5: Research rigor Design-science research relies upon the application of rigorous methods in both the construction and evaluation of the design artifact.

Guideline 6: Design as a search process The search for an effective artifact requires utilizing available means to reach desired ends while satisfying laws in the problem environment.

Guideline 7: Communication research Design-science research must be presented effectively both to technology-oriented as well as management-oriented audiences.

One of the difficulties of design science is projecting mental model of the process, especially

for IT and IS related research such as one conducted in this thesis. This problem was

addressed by (Ken Peffers, 2006), they provided a new model of design science research to

be used specifically in the IS world. This model had three objectives: was consistent with

prior literature, providing a nominal process model for doing DS research, and providing a

mental model for presenting and appreciating DS research in IS. The model was called DSRP

and included six steps of processes: problem identification and motivation, objectives for a

solution, design and development, demonstration, evaluation, and communication.


Aldo Elam Majiah

Figure 33: DSRP Model (Ken Peffers, 2006)

Brief explanations of the six processes are as follows:

1. Problem identification and motivation. Define the specific research problem and justify

the value of a solution. Resources required for this activity include knowledge of the

state of the problem and the importance of its solution.

2. Objectives of a solution. Infer the objectives of a solution from the problem definition.

The objectives should be inferred rationally from the problem specification.

3. Design and development. Create the factual solution. Such artifacts are potentially, with

each defined broadly, constructs, models, methods, or instantiations.

4. Demonstration. Demonstrate the efficacy of the artifact to solve the problem. This could

involve its use in experimentation, simulation, a case study, proof, or other appropriate

activity.

5. Evaluation. Observe and measure how well the artifact supports a solution to the

problem. This activity involves comparing the objectives of a solution to actual

observed results from use of the artifact in the demonstration.

6. Communication. Communicate the problem and its importance, the artifact, its utility

and novelty, the rigor of its design, and its effectiveness to researchers and other

relevant audiences, such as practicing professionals, when appropriate.

The DSRP model is suitable to be used in IS research. The processes and steps described in

the model are specifically developed for DS research in the world of IT. Hence this model is

used in this research as the basis of research methodology.

2.6 Theoretical framework

The overall methodology for the thesis is taken from DSRP model from (Ken Peffers, 2006).

For design and development part, we will use AD risk assessment framework as a method for

developing IT artifacts. The methodology and theoretical framework diagram is shown in

figure 34:

Problem identification

and motivation

Objectives of a solution

Design & development

Demonstration Evaluation Communication


Aldo Elam Majiah

Figure 34: Methodology and theoretical framework

For the risk assessment framework, we are using AD risk assessment framework which has

seven steps as shown in figure 34. This AD risk assessment framework will be conducted on

six AD components which represent characteristics of AD. Figure 35 shows representation of

AD risk framework on AD components.

Figure 35: AD components revolves around risk assessment framework

AD risk assessment framework

AD design & boundary

AD management

Policy implementation

Security of AD computer members

Security of network

Security of DC


Aldo Elam Majiah

CHAPTER 3 - RESEARCH METHODOLOGY

The way in which this research is conducted will follow methodology shown in the figure

below. The methodology is derived using DSRP model from (Ken Peffers, 2006).

Figure 36: Thesis methodology


Aldo Elam Majiah

3.1 Steps of research methodology

Detailed steps are as follows:

1. Define research problem and objectives. Problems in performing a secure

implementation of Active Directory in most enterprises were presented using fishbone

diagram. Probable causes of the problem were identified. Author then select a particular

problem area for thesis topic and developed research questions and research objectives.

2. Conduct literature review. Literature reviews on related sources were conducted,

resulting in theoretical framework for answering the research questions. The result of

this step is a risk assessment framework for assessing AD. AD was also divided into six

components to ease the finding of the threats.

3. Data gathering. Data gathering was conducted in a real AD implementation in an

organization. The data gathering activities followed (NIST, 2002), in which it stated

that techniques that can be used for data gathering are: questionnaire, on-site interviews,

document review, and use of automated scanning tools. The author performed on-site

interview, automated vulnerability scan, and penetration testing in the organization.

4. Design and development using theoretical framework. AD risk assessment framework

was used on six components of AD implementation in the organization. The result of

this activity is a set of recommended countermeasures for AD security implementation

in the said organization.

5. Demonstrate countermeasures. The countermeasures recommended from previous step

were demonstrated to measure their effectiveness. The demonstration was conducted in

a prototype AD environment of the organization.

6. Evaluate. Experts’ judgments were used to validate AD risk framework, AD

components, and countermeasure results. Lastly, conclusion and on the research and

suggestion on future works were presented.

3.2 Key activities for design and development

The following are key activities of the theoretical framework against AD components.

3.2.1 AD system characterization In this step we perform identification of the AD, along with the resources and the information

that constitute the system (NIST, 2002). AD system characterization establishes the scope of

risk assessment, defines operational boundaries, and provides information (hardware,

software, network connectivity, and responsible division or PIC). All of these are essential for

defining the risk.

There are several researches related with developing activities for AD system

characterization and threat identifications. Research from (ISACA, 2010) is one of them; it

defines activities for auditing AD and has detailed auditing questions and scenarios.

Unfortunately, this research does not include audit of AD servers and workstations computer

members which build the larger part of AD domain. It also does not include audit of Domain


Aldo Elam Majiah

Name Service (DNS) management which usually becomes first target of attackers who are

trying to enumerate list of all computers members in an AD.

On the other hand, there are researches which are focused on the security of computers in the

network. (Sandberg, 2013)’s research points out a minimal set of technical countermeasures

for securing endpoints computers or devices. These sets are: inventory of hardware and

software, patch management, security configuration management, mobile devices

management if the organization is using mobile devices as endpoints. Likewise, (Center for

Strategic and International Studies, 2013) and (Defence Signals Directorate, 2012) describe

sets of mitigation strategies for securing computers in the network.

In AD system characterization step, we will define the characterization of AD into six

components as previously described in chapter 2.1.3. These activities are derived from

literature reviews with the emphasis from the researches that have been discussed above:

(ISACA, 2010), (Sandberg, 2013), (Center for Strategic and International Studies, 2013), and

(Defence Signals Directorate, 2012). There are 64 key activities or characterization of the AD

system that need to be performed. These activities are divided into six AD components; AD

design & boundary has 6 key identification activities, AD management has18 activities,

policy implementation has 6, security of AD computer members has 17, security of network

component has 8, and the last component is security of DC which has 9 key identification

activities.

Figure 37: Distribution of key identification activities

6

18

6 17

8

9

Key activities


AD management


Security of AD computermembers

Security of network

Security of DC


Aldo Elam Majiah

Key activities for each component are as follows:

AD design & boundary:

Identify forest and domain structure (for example: the implemented AD is single forest,

multiple domains).

Obtain a hierarchal diagram representation of the AD structure, starting with the forest

down to domain.

Review of forest or domain trust relationship(s) and determine that external trusts are

permitted only with prior authorization.

Determine whether there are appropriate administrative controls to prevent

unauthorized granting of trusts.

Review AD design documentation.

Determine if the forest or domain structure provides for a separation between service

administrators, considering administrative and security boundaries between

forest/domain administrators.

AD management:

Identify domain and forest functional level.

Identify servers holding FSMO roles.

Identify domain tree structure.

Determine if OU deployment has already aligned with organization’s structure.

Determine if security group deployment has already aligned with organization’s needs.

Identify the organization’s personnel responsible for AD, considering personnel

capabilities, workload, skills, and separation of duties.

Review existing AD documentations (policies, logs, previous audit, etc).

Determine if high privilege accounts groups are controlled (for example Domain

Admins, Enterprise Admins, and Schema Admins groups).

Review delegation of tasks to groups/accounts.

Review if separation of daily accounts and administrative accounts exists.

Identify accounts used for service, applications, or other accounts which passwords are

rarely changed.

Identify restricted groups.

Identify existing change management for AD.

Review AD log monitoring capabilities.

Determine if AD functional level (forest or domain) is already the highest for DC’s

operating system.

Review AD availability (existence of secondary / backup domain controller) for each

site.

Determine if there are backup procedures for AD.

Check whether there are periodic restore testing procedures for AD backup.


Aldo Elam Majiah

Policy implementation:

Identify whether existing OU deployment is suitable for GPO implementation.

Review of security settings policy implementation: Account policies (password

policies, account lockout policy, Kerberos policy).

Review of security settings policy implementation: audit policy.

Review of security settings policy implementation: user rights assignments.

Review of security settings policy implementation: security options.

Review of security settings policy implementation: event log.

Security of AD computer members:

Identify patch management system (patch for OS and applications).

Identify existence of application whitelisting (permitted applications) in servers and

workstations.

Identify controlled used of administrative privilege.

Identify if there is secure configurations or procedures for deploying servers and

workstations (for example: disabling unrequired applications or services, patching

before deploying servers or workstations).

Identify correct deployment of anti-virus and anti-malware software (check if antivirus

software has been installed, determine if antivirus software can be disabled or removed,

check if the signature files are updated regularly).

Identify removable and portable media control.

Identify continues vulnerability scanning processes for AD computer members.

Identify data recovery capability.

Identify whether host-based firewall is configured.

Identify whether there users’ education and awareness.

Identify whether LanMan is still used on servers/ workstations.

Identify whether there are security-related incidents in helpdesk logs.

Identify exploits and attacks.

Identify users’ related threats.

Identify natural threats.

Identify hardware related threats.

Identify if virtual machine environment is used

Security of network:

Identify wireless AP network segregation.

Review whether there are secure network configurations documents for network

devices (such as firewalls, routers, and switches).

Identify whether network ports, protocols, and services are limited and controlled.

Identify network segmentation / segregation.

Identify the use of network based intrusion detection / prevention system.

Identify the use of website blacklisting in the proxy.


Aldo Elam Majiah

Determine if the cabling rooms are locked with limited access and the access are

logged.

Determine if management ports of domain controllers and servers (RDP, SSH) are

connected to a dedicated management network (segmented from other networks and

only admin workstations can connect to them).

Security of DC:

Determine if all DCs have already the latest security patches / service packs.

Identity if there are secure configuration documentations or procedures for deploying

DC.

Check whether DC is placed in a secure physical facility.

Identify correct deployment of anti-virus and anti-malware software on DC (check if

antivirus software has been installed, determine if antivirus software can be disabled or

removed, check if the signature files are updated regularly).

Identify whether DC runs only essential services or features.

Determine whether only authorized personnel are allowed to access DC physically.

Determine if DC is using a backup power supply (UPS).

Determine if DC can be booted using alternative OS.

Determine if DC is using a secure out-of-band management network.

3.2.2 Threat sources and events identification In this step we will identify both threat sources and events. Identifying threat sources

comprise of identifying threat sources from point of view capability, intent, and targeting

characteristics (NIST, 2012). The focus of this step is on identifying possible IS threats.

These threats are sources, events, actions, or inactions that could harm of the organization

(Mark RM Talabis, 2013).

Key activities:

Identify threat sources

Identify threat events

Determine and assess the relevance of threat sources to AD implementation in the

organization

Determine and assess the relevance of threat events to AD implementation in the

organization

3.2.3 Identification of vulnerability Using output from previous activities of finding threats sources and events, next we deal with

identifying vulnerabilities that can be leveraged by these threat sources and events and

produce threat and vulnerability pair (Mark RM Talabis, 2013). (NIST, 2012) states that there

could be a many-to-many relationship between threat events and vulnerabilities. Multiple


Aldo Elam Majiah

threat events can exploit a single vulnerability and multiple vulnerabilities can be exploited

by a single threat event.

Key activities:

Identify vulnerabilities, taken into account data from questionnaires, automated

vulnerability scan, and penetration testing report.

3.2.4 Determination of likelihood of occurence Key activities, taken from (NIST, 2012):

Define assessment table for likelihood of event initiation or occurrence.

Define assessment table for threat event resulting in impact.

Determine and assess overall likelihood

Table 4: Table for likelihood of event initiation or occurrence (NIST, 2012)

Value Description 5 (very high) Adversary is almost certain to initiate the threat event or error, accident, or act of nature is almost

certain to occur; or occurs more than 100 times a year

4 (high) Adversary is highly likely to initiate the threat event or error, accident, or act of nature is highly likely to occur; or occurs between 10-100 times a year.

3 (moderate) Adversary is somewhat likely to initiate the treat event or error, accident, or act of nature is somewhat likely to occur; or occurs between 1-10 times a year.

2 (low) Adversary is unlikely to initiate the threat event or error, accident, or act of nature is unlikely to occur; or occurs less than once a year, but more than once every 10 years.

1(very low) Adversary is highly unlikely to initiate the threat event or error, accident, or act of nature is highly unlikely to occur; or occurs less than once every 10 years.

Table 5: Table for likelihood of threat event resulting in impact (NIST, 2012)

Value Description 5 (very high) If the threat event is initiated or occurs, it is almost certain to have adverse impacts

4 (high) If the threat event is initiated or occurs, it is highly likely to have adverse impacts

3 (moderate) If the threat event is initiated or occurs, it is somewhat likely to have adverse impacts

2 (low) If the threat event is initiated or occurs, it is unlikely to have adverse impacts.

1(very low) If the threat event is initiated or occurs, it is highly unlikely to have adverse impacts.

Table 6: Table for determining/assessing overall likelihood (NIST, 2012)

likelihood of event initiation or occurrence:

likelihood of threat event resulting in impact:

1(very low) 2 (low) 3 (moderate) 4 (high) 5 (very high)

5 (very high) 2 3 4 5 5

4 (high) 2 3 3 4 5

3 (moderate) 2 2 3 3 4

2 (low) 1 2 2 3 3

1(very low) 1 1 2 2 2


Aldo Elam Majiah

3.2.5 Determination of impact magnitude Key activities, taken from (NIST, 2012):

Define assessment table for assessing impact of threat events

Determine and assess impact

Table 7: Table for assessing impact of threat events (NIST, 2012)

Description 5 (very high) The threat event could be expected to have multiple severe or catastrophic adverse effects on

organizational operations, organizational assets, individuals, other organizations, or the Nation.

4 (high) The threat event could be expected to have a severe or catastrophic adverse effect on organizational operations, organizational assets, individuals, other organizations, or the Nation. A severe or catastrophic adverse effect means that, for example, the threat event might: (i) cause a severe degradation in or loss of mission capability to an extent and duration that the organization is not able to perform one or more of its primary functions; (ii) result in major damage to organizational assets; (iii) result in major financial loss; or (iv) result in severe or catastrophic harm to individuals involving loss of life or serious life-threatening injuries.

3 (moderate) The threat event could be expected to have a serious adverse effect on organizational operations, organizational assets, individuals other organizations, or the Nation. A serious adverse effect means that, for example, the threat event might: (i) cause a significant degradation in mission capability to an extent and duration that the organization is able to perform its primary functions, but the effectiveness of the functions is significantly reduced; (ii) result in significant damage to organizational assets; (iii) result in significant financial loss; or (iv) result in significant harm to individuals that does not involve loss of life or serious life-threatening injuries.

2 (low) The threat event could be expected to have a limited adverse effect on organizational operations, organizational assets, individuals other organizations, or the Nation. A limited adverse effect means that, for example, the threat event might: (i) cause a degradation in mission capability to an extent and duration that the organization is able to perform its primary functions, but the effectiveness of the functions is noticeably reduced; (ii) result in minor damage to organizational assets; (iii) result in minor financial loss; or (iv) result in minor harm to individuals.

1(very low) The threat event could be expected to have a negligible adverse effect on organizational operations, organizational assets, individuals other organizations, or the Nation.

3.2.6 Risk determination Determining risk level from threat events while considering both the likelihood and impact

magnitude of the events (NIST, 2012).

Key activities:

Define assessment table for determining level risk as combination of likelihood and

impact.

Describe level of risk assessment.

Determine and assess risk.

Table 8: Table for determining level risk as combination of likelihood and impact (NIST, 2012)

Likelihood Impact

1(very low) 2 (low) 3 (moderate) 4 (high) 5 (very high)

5 (very high) 1 2 3 4 5

4 (high) 1 2 3 4 5

3 (moderate) 1 2 3 3 4

2 (low) 1 2 2 2 3

1(very low) 1 1 1 2 2


Aldo Elam Majiah

Table 9: Table for describing level of risk assessment (NIST, 2012)

Value Description 5 (very high) Very high risk means that a threat event could be expected to have multiple severe or catastrophic

adverse effects on organizational operations, organizational assets, individuals, other organizations, or the Nation.

4 (high) High risk means that a threat event could be expected to have a severe or catastrophic adverse effect on organizational operations, organizational assets, individuals, other organizations, or the Nation.

3 (moderate) Moderate risk means that a threat event could be expected to have a serious adverse effect on organizational operations, organizational assets, individuals, other organizations, or the Nation.

2 (low) Low risk means that a threat event could be expected to have a limited adverse effect on organizational operations, organizational assets, individuals, other organizations, or the Nation.

1(very low) Very low risk means that a threat event could be expected to have a negligible adverse effect on organizational operations, organizational assets, individuals, other organizations, or the Nation.

3.2.7 Countermeasure recommendation Providing controls for mitigating or eliminating risks from previous step. The output of this

step is recommendation of controls / countermeasure for each identified risks or alternative

solutions for mitigating the risk (NIST, 2002).

Key activities:

Recommend countermeasure for each risk, taking into consideration effectiveness of

recommended options (system compatibility), legislation and regulation, organizational

policy, operational impact, and safety and reliability.


Aldo Elam Majiah

CHAPTER 4 – RISK ASESSMENT & ANALYSIS

4.1 Design and development (risk assessment)

4.1.1 AD system charaterization These are data from risk assessment step 1, characterizing AD. The organization where the

data was taken from is an educational institution organization, throughout this thesis it will be

referred as “organization”. The data were taken using the following techniques: peer-to-peer

interviews, automated vulnerability scan, and penetration testing. These data are confidential;

hence the omitting of the organization name, involved personnel, and other infrastructure

information will be conducted if deemed necessary.

Original forms and edited versions of AD characterization assessments are available in the

appendix (appendix 1 and 2). Penetration testing report and result of automated vulnerability

scanning are disclosed partially and carefully in chapter 4.1.3, identification of vulnerability.

The whole system characterization processes took about 5 working days on March 2014. It

included a penetration testing activity and automated vulnerability scan of the organization’s

entire network. The creation of penetration testing report for the organization took an

additional of 2 weeks’ time.

To perform the penetration testing and vulnerability scan of the network, the author was

provided with a WIFI access from a library inside the organization’s premises. This WIFI

access turned out to be connected to the entire organization’s network.

For penetration testing activity, the author used many tools which are mainly provided in Kali

Linux. Kali Linux is a Debian-based Linux distribution designed for penetration testing. It

consists of hundreds of penetration testing tools. Some of these tools, for example nmap,

Metasploit framework, and nbtscan, were heavily used during this activity. The author also

used a vulnerability scanning tool, Nessus. Nessus is a remote vulnerability scanning tool,

which scans a computer and raises an alert if it discovers vulnerabilities on the target systems.

Questionnaires to the organization were conducted at the end of the penetration testing

project. The organization was presented by three IT personnel; IT system administrator, GA

& IT manager, and IT supervisor. Most of the answers from the questionnaires were provided

by the system administrator.

4.1.2 Threat sources and events identification These are relevant threat sources and events related to the organization in general and in

particular to AD implementation in the organization.

To help identifying threat sources, first we shall introduce threat sources taxonomy from

(NIST, 2012):


Aldo Elam Majiah

Table 10: Threat sources taxonomy (NIST, 2012)

Type of threat sources Description ADVERSARIAL - Individual

- Outsider - Insider - Trusted Insider - Privileged Insider

- Group - Ad hoc - Established

- Organization - Competitor - Supplier - Partner - Customer

- Nation-State

Individuals, groups, organizations, or states that seek to exploit the organization’s dependence on cyber resources (i.e., information in electronic form, information and communications technologies, and the communications and information-handling capabilities provided by those technologies).

ACCIDENTAL - User - Privileged User/Administrator

Erroneous actions taken by individuals in the course of executing their everyday responsibilities.

STRUCTURAL - Information Technology (IT) Equipment - Storage - Processing - Communications - Display - Sensor - Controller

- Environmental Controls - Temperature/Humidity Controls - Power Supply

- Software - Operating System - Networking - General-Purpose Application - Mission-Specific Application

Failures of equipment, environmental controls, or software due to aging, resource depletion, or other circumstances which exceed expected operating parameters.

ENVIRONMENTAL - Natural or man-made disaster - Fire - Flood/Tsunami - Windstorm/Tornado - Hurricane - Earthquake - Bombing - Overrun

- Unusual Natural Event (e.g., sunspots) - Infrastructure Failure/Outage

- Telecommunications - Electrical Power

Natural disasters and failures of critical infrastructures on which the organization depends, but which are outside the control of the organization. Note: Natural and man-made disasters can also be characterized in terms of their severity and/or duration. However, because the threat source and the threat event are strongly identified, severity and duration can be included in the description of the threat event (e.g., Category 5 hurricane causes extensive damage to the facilities housing mission-critical systems, making those systems unavailable for three weeks).

Next, to help identifying threat events, we derive a list of threat events. Some of the threats

events were taken from (NIST, 2012), others were taken from Microsoft’s GPO

implementation, but most of them are created by the author. Each of these threats has

identification number which will be used in subsequent steps.

Overall, there are 221 threat events divided into six AD components as shown in figure 38.

Six threats identified in AD design and boundary, 19 threats identified in AD management,

80 threats identified in policy implementation, 77 threats in security of AD computer

members, 26 threats identified in security of network, and 13 threats identified in security of

DC.


Aldo Elam Majiah

Figure 38: Distribution of threat events

Details of threat events, its description, and identification number of each threat are described

in detail in appendix 3.

4.1.3 Identification of vulnerability To identify the vulnerability of each threat, the author takes consideration of interview result

of AD system characterization (appendix 1 and 2), vulnerability scanning report, and

penetration testing report for that has been performed for the organization.

There were 129 hosts scanned by Nessus vulnerability scanner (Majiah, 2014). The

automated scanning by vulnerability scanner found a total of 189 vulnerabilities. The scanner

automatically categorized these vulnerabilities into five groups, based on their severity level:

critical, high, medium, low, and info (information only). Critical vulnerabilities was detected

as many as 6% of all detected vulnerabilities, high 11%, medium 22%, low 6%, and the rest

was categorized as information (56%).

Figure 39: Vulnerability scan results

6 19

80

77

26 13

Identified threats

AD design and boundary

AD management


AD computer members

Security of network.

Security of DC

Critical, 6

High, 11

Medium , 22

Low, 6

Informational, 56

Vulnerabilities


Aldo Elam Majiah

The critical vulnerabilities were dominated by missing Windows OS patches (7 critical

missing patches detected on 20 hosts) and Apache-related vulnerabilities (2 vulnerabilities on

4 hosts). Vulnerabilities with high severity level were dominated by PHP-related

vulnerabilities (13 vulnerabilities detected on 45 hosts).

Penetration testing resulted in total complete took over of the Active Directory. Pen-tester

was able to acquire a high privilege domain accounts through brute force attack on the

domain controller. There were a total of 16 findings reported on the penetration testing report

(Majiah, 2014), with two findings categorized as high risk. Six of these findings related

directly to AD implementation in the organization network. Related findings to AD were

finding no. 1, 2, 3, 4, 8, and 9 as shown figure 39.

Figure 40: Summary of penetration testing report

The identification of vulnerabilities in relation to the threats events are described in detail in

appendix 4. Most of the vulnerabilities in the organization’s AD were caused by weak

implementation of password policies, unimplemented security GPOs, availability problem,

and incomplete patch management on domain computers. Please note that appendix 4 uses

the same threat identification numbering as defined in appendix 3.

4.1.4 Determination of risk level and countermeasure Next we determine the likelihood, impact, risk level, and at last the countermeasure for the

threat. These steps are defined in section 3.2.4 to 3.2.7. In those sections we can see the

definition of each level of likelihood, impact, and risk level. Matrix for determining overall

risk is also provided in chapter 3.2.6. All the results are presented in appendix 5.


Aldo Elam Majiah

The result of the risk assessment is shown in the figure below. For AD implementation on the

organization there were 5 very high risk threats, 21 high risk threats, and 79 moderate threats.

The rest of the threats have low (86 threats) and very low risks (30 threats).

Figure 41: Risk assessment result

The final risk level is categorized into five levels as described in section 3.2.6 where risk

assessment levels (very low, low, moderate, high, and very high) are clearly defined. Risk

level for very low and low risk will be assumed as accepted by the organization; hence

countermeasures are not defined for these two levels. Countermeasures are given for risks

that could cause serious effects to the organization, which are moderate, high, and very high

risks (assumed). For details on the risk level of each threat and the countermeasure

recommendations, please refer to appendix 5.

4.2 Demonstrate countermeasure (prototyping)

In this subchapter the author select several countermeasures and implement them in a virtual

machine environment for testing purposes and demonstrating its effectiveness. It was not

possible to implement the countermeasures directly in the original AD environment because

it may have implications in the production network.

But demonstrating countermeasure is a step in the methodology, hence it must be done. Thus

the author selected a virtual machine environment to show the implementation of these

countermeasures. To achieve this, the author created an exact replica of the domain under

assessment. This AD replica was created during penetration testing activity by promoting a

VM to a secondary DC. This secondary DC then used in prototyping the countermeasures.

0

10

20

30

40

50

60

70

80

90

100

VERY HIGH HIGH MODERATE LOW VERY LOW

Risk assessment results


Aldo Elam Majiah

It is also worth noted that not all countermeasures are tested; only countermeasures which are

technical in nature and are possible to be implemented in a VM environment are selected.

Other countermeasures, such as the ones related to implementation of policies or users

training cannot be implemented and measured in virtual machines environment, instead they

have to be implemented for the users in the original environment and its effectiveness also

cannot be measured in a short time.

The AD for this demonstration consists of approximately of 800 users and 370 computers.

This is a single domain, single forest AD that does not have trust relationship with other

entities. The AD has only one site, the default-first-name-site.

Figure 42: AD for prototyping

Disable booting from alternative OS

If BIOS is not protected then adversaries may shutdown a host (or DC) and gain

access to sensitive files such as SAM account files. SAM account files are files where

database of user accounts are saved. If an adversaries could get these files, than he/she

may be able to perform offline password cracking. The following screenshots show

how an adversaries boot a DC using alternative bootable CD, access, and copied the

ntds.dit and system security files out of the DC.


Aldo Elam Majiah

Figure 43: Access files using alternative OS

After the files are copied outside, adversaries could extract password hashes out of these files

and crack them using offline password cracking program such as Ophcrack as shown in

figure 44.

Figure 44: Offline password cracking using Ophcrack

To thwart this threat, administrators need to disable booting using portable USB or CD/DVD

media in the BIOS and protect BIOS using password.

Upgrade to higher domain and forest functional level

DC in an AD can run different versions of Windows Server OS. The functional level of a

domain or forest depends on which versions of Windows Server OS are running on the DC in

the domain or forest, it also controls which advanced features are available in that domain or

forest. Raising the functional level allows the introduction of advanced features, including

newer security features, but also limits the versions of Windows Server that can run on

domain controllers in the environment. AD DS has two types of functional levels: domain

functional level and forest functional level (Microsoft, 2010).


Aldo Elam Majiah

The organization has a single DC that runs on Windows Server 2008 but the functional level

is 2003. To upgrade domain functional level, simply right click at the domain name in the

ADUC and select raise domain functional level. Likewise, to raise forest functional level,

simply right click ADDT and select raise forest functional level.

Raising functional level to 2008 introduces newer security features such as; fine-grained

password policies which enables specify password and account lockout policies for users and

global security groups in a domain, increased Kerberos encryption using AES 128 and 256,

accidental deletion protection feature for AD objects, and interactive failed logon

information.

Figure 45: raising functional levels

Create secondary DC

Creating a secondary DC in the domain improves the availability and reliability of domain

services. It also provides fault tolerance, load balancing between DC, and additional

infrastructure support for the sites. A single DC means the DC becomes a liability as it

functions as single-point-of-failure.

Figure 46 shows additional domain controller is added for the site, efficiently thwarting

availability risk for AD. The hostnames of the DCs are 2k3pentest and 2k8pt, serving default-

first-site-name of xxxjkt.com domain.

Figure 46: Primary and secondary DC


Aldo Elam Majiah

In addition to provide solution to AD availability problems, a secondary DC can also function

as a backup of FSMO roles. FSMO is five special roles, two per domain and three per forest,

which are vital to ensure the smooth running of AD. The forest roles are schema and domain

naming master; while domain roles are RID, PDC emulator, and infrastructure master.

Screenshot below shows a successful transfer of RID master role into another DC, which will

not be possible if the organization does not have a secondary DC.

Figure 47: Successfully transferred RID master role

Create computer-based OU

To ease deployment of GPO, the organization needs to deploy OU based on the computer

functions (e.g. servers and workstations), in addition to existing user-based OUs. Screenshot

below shows the implementation of such OUs; computers are categorized into servers and

workstations, and workstations are further categorized as teachers_computers, library, lab, etc

Figure 48: Computer-based OU deployment


Aldo Elam Majiah

Limit & control high privilege domain accounts

The amounts of high privilege domain accounts (enterprise admin, schema admin, and

domain admin accounts) are too high. Reducing the number of current domain admins from 8

accounts into only 3 accounts will provide better control on them.

Figure 49: Reduce number of domain admins

Controlling the use of high privilege domain accounts is also necessary to mitigate the pass-

the-hash attack, a kind of attack that arises due to the fact that password hashes are never

salted in Windows environment. In this attack, usually high privilege domain accounts, i.e. a

domain admin account, is targeted. Once a domain admin account is compromised, an

adversary can use this high privilege domain accounts to move from one host to another.

Since domain admins accounts are usually have strong passwords, adversaries may not be

able to crack the hash and found the original plaintext. But since pass-the-hash attack is

invented, it is not necessary to know the password, knowing the hash is sufficient. It gives

adversaries a way to compromise all computer member of the domain since domain admins

are members of administrator groups in all AD computer member by default.

As an example, we configure a domain admin account aldoel to be able to logon from one

host only, 2k3pentest.


Aldo Elam Majiah

Figure 50: Configure an account ability to logon from only one host

Next, we assume that an adversary has compromised this aldoel domain admin account and

already acquired the hash of this account. The adversary then tries to comprise host

192.170.153.158 using the hash from the account using metasploit. The attempt fails as

shown in figure below because the account is not configured to be able to logon to that host.

Figure 51: Fail pass-the-hash attack

Utilize the use of restricted groups

Instead of using high privilege domain accounts such as domain admins for troubleshooting

or installing applications on workstations, we can utilize the use of restricted groups.

Screenshot below shows an example of deployment of a restricted group called helpdesk as

administrator in workstations. The group is deployed utilizing GPO to all workstations in the

domain to ensure the helpdesk group administrative access to all workstations.


Aldo Elam Majiah

Figure 52: Deploying restricted group

Utilizing this feature, helpdesk group has become member of administrators group in all

workstation thus enabling helpdesk team to troubleshoot users’ workstation with

administrative privilege without using a domain admin account.

Separate account for administrators

To minimize the use of high privilege accounts such as domain admin accounts, it is best to

create two accounts for domain administrators. One account is a normal user account for

performing daily task for the administrator (browsing, creating office documents, etc), and

the other one is a high privilege account. For example, we can create a normal user aldoel

and aldoel-adm as the domain admin account. Every time the administrator needs to perform

domain related tasks that needs a domain admin privilege, he can utilize run as command.

Figure 53: Using run as for administrative tasks


Aldo Elam Majiah

Implement secure password policies

Password policy of the organization was found very lacking. Password complexity was not

enabled, and minimum password length was only 3 characters.

Figure 54: Weak password policy

This weak password policy created basic password problems; penetration testing result

showed the following weak domain users passwords:

1. Passwords which were the same as the usernames: 75 instances.

2. 233 domain users were using “123” as the password of their accounts.





7. 3 domain users were using “password” as the password of their accounts.

8. 366 domain users were using 4 character password or less than 4 characters.

Screenshot below shows a more secure password policy implementation. A minimum

password length of 8 characters and password complexity are implemented. Password history

and maximum password age are reduced to 10 and 30 days, respectively. Implementing

stronger password policy such as this should eliminate password problems found during

penetration testing. A regular check of domain user passwords, e.g. once every 6 months, is

necessary to ensure all domain users are free of weak password problems.

Figure 55: Stronger password policy


Aldo Elam Majiah

Implement secure account lockout policies

A strong account lockout policy can frustrate adversaries who perform brute force attack on

domain accounts. Current account lockout policy of the organization proved to be weak as

only one policy was implemented; the account lockout threshold was set to 0.

Figure 56: Weak account lockout policy

This weak policy enabled the penetration tester to perform brute force attack using medusa.

Medusa is an online password brute force application, it is described as a speedy login brute

force application with modules available to support almost any service that allows remote

authentication using a password, including: FTP, HTTP, CVS, MySQL, POP3, IMAP, MS-

SQL, PostgreSQL, VNC, SMTP-AUTH, and Telnet.

Figure 57 shows real penetration testing activity on the organization’s domain controller.

Penetration tester performed brute force attack SMB account passwords on the domain

controller and found weak passwords used in many domain accounts.

Figure 57: Password cracking using Medusa


Aldo Elam Majiah

It is imperative to implement stronger account lockout policy to minimize the possibility of a

successful brute force attack on domain users’ passwords. Account lockout threshold was set

to 3 invalid logon attempts. This means after 3 times of incorrect password attempt, the

account is locked out. The account is locked out for 30 minutes and then it releases back, as

described in Account lockout duration policy. This policy, together with Reset account

lockout counter after policy, helps a possibility to undo mass account lockout after 30

minutes if a brute force attack is underway.

Figure 58: Stronger account lockout policy

To test the effectiveness of this feature, we tried the same password brute force attack using

medusa. The result showed that the account being brute forced was locked out after 3 invalid

password brute force attempt. The new account lockout policy was a success.

Figure 59: Testing account lockout policy

Perform regular AD backup

Perform AD backup regularly is as important as testing the backup result in also a scheduled

restore testing process. We can backup AD using default Windows server backup feature

since Active Directory is backed up as part of system state. Third party AD backup software

which offers more functionality is also available in the market.


Aldo Elam Majiah

System state includes AD and all other system components and services on which AD is

dependent. It consists of system startup files, File Replication service (the SYSVOL

directory), system registry, COM+ class registration database, certificate Services database,

DNS, Cluster service and the AD itself. DNS data includes Active Directory–integrated DNS

zone information. AD data consist of the following: AD database (ntds.dit), checkpoint file,

transaction logs and reserved transaction logs.

Figure 60: Backup AD using Windows Server backup

Automatic patch management system

Ensure all OS are receiving updates. For Windows system, this can be done by setting

automatic update to check and install patches directly from Microsoft or, preferably, using a

WSUS server deployment.

WSUS enables IT administrators to deploy latest Microsoft patch updates to computers

running the Windows OS. By using WSUS, administrators can manage distribution of

updates released through Microsoft Update to computers in their network (Microsoft, 2014).

There are two general steps when deploying WSUS server: deploy the server and distribute

patch update configuration using GPO. As an example, say we have deployed a WSUS server

in IP address 192.170.153.155. To ensure uniform configuration throughout the domain,

administrators need to configure all computers in the domain to update the patch using this

WSUS server. This can be done via GPO, as shown in the next figure.


Aldo Elam Majiah

Figure 61: WSUS configuration GPO

Administrators also need to check regularly computers that are not correctly receiving and

installing patches intended for them. This information can be viewed from WSUS console.

Computers that are not correctly patched must be fixed one by one to ensure no missing

patches were found throughout the domain.

Top test this countermeasure, we created a server that found vulnerable against patch MS08-

067. Using Metasploit framework, which is a tool for developing and executing exploit code

against a remote target machine, we launched MS08-067 exploit against this server. Since the

server was unpatched, the exploit worked. A session was created and the attacker gained

system access to the server.

Figure 62: Successful exploit using Metasploit


Aldo Elam Majiah

Next, we patched this server using MS08-067 patch from Microsoft and we tried to exploit

this server the second time. As seen in the figure below, the exploit failed, thus no session

was created.

Figure 63: Fail exploit attempt

Perform regular vulnerability assessment

Regular vulnerability scanning of the organization’s network is very important as the process

checks systems for weaknesses in a network, computer OS, or application. This enables an

organization to identify vulnerable systems before these systems exploited by adversaries

such as exploits, viruses, Trojans, or other attacks.

Vulnerability scanner such as Nessus or OpenVAS will first look for IP addresses, open

ports, OS, and applications running throughout the network. Once the network is mapped and

identified, the scanner will try to determine patch completeness of the OS and then checks for

known vulnerabilities.

The organization was scanned using Nessus vulnerability scanner and the result showed a lot

of detected vulnerabilities. These vulnerabilities must be mitigated; some can be mitigated by

applying patches while others may need more drastic changes such as completely upgrading

the system. Screenshot below shows a portion vulnerability scan result of the organization’s

network. The scan detected vulnerabilities and categorized them into different colors,

expressing their level of criticality.

Figure 64: Nessus scan result


Aldo Elam Majiah

These automated processes of proactively identifying security vulnerabilities must be

performed regularly to ensure there is not any high risk vulnerability exist on the network.

After performing vulnerability scan the organization will need to implement a process for

addressing the identified vulnerabilities.

Uninstall unnecessary ports and services

Only runs needed services is one of the basic strategies of attack surface reduction. There are

fewer security risks if a system turns off unnecessary functionality.

Consider two systems below which had been scanned using nmap, a security scanner

application used to discover hosts and services on that hosts. The first system (with IP

address x.x.x.x) has more surface attack area compare to the second system (y.y.y.y). The

first system has more open ports and services compare to the second. Investigation must be

performed to determine whether all the services and ports in the first system (and the second

one) are really necessary.

Nmap scan report for x.x.x.x

Host is up (0.0044s latency).

Not shown: 976 closed ports

PORT STATE SERVICE

53/tcp open domain

80/tcp open http

88/tcp open kerberos-sec

135/tcp open msrpc

139/tcp open netbios-ssn

389/tcp open ldap

445/tcp open microsoft-ds

464/tcp open kpasswd5

593/tcp open http-rpc-epmap

636/tcp open ldapssl

1688/tcp open nsjtp-data

3071/tcp open csd-mgmt-port

3268/tcp open globalcatLDAP

3269/tcp open globalcatLDAPssl

3389/tcp open ms-wbt-server

5357/tcp open wsdapi

49152/tcp open unknown








MAC Address: 5C:F3:FC:F1:68:0B (IBM)

Nmap scan report for y.y.y.y


Aldo Elam Majiah

Host is up (0.0031s latency).

Not shown: 993 filtered ports

PORT STATE SERVICE

80/tcp open http

135/tcp open msrpc

139/tcp open netbios-ssn

445/tcp open microsoft-ds

1433/tcp open ms-sql-s

3389/tcp open ms-wbt-server

5357/tcp open wsdapi

MAC Address: 5C:F3:FC:F1:62:93 (IBM)

It is also worth noted that although attack surface reduction helps prevent security attacks, it

does not mitigate the amount of damage an adversaries could inflict once vulnerability is

found on the system.

Upgrade to secure protocols

During penetration testing, insecure protocols such as FTP, HTTP, and Telnet were found in

the organization’s network. FTP was found to be used in 6 hosts, HTTP in 43 hosts, and

Telnet was used in 8 hosts. These protocols were insecure and adversaries may take

advantage of these protocols for example by eavesdropping or intercepting the

communications using ARP spoofing technique. If the communications to or from these hosts

are intercepted, adversaries will be able to get username and passwords used for these

services since all communications are sent in plain text. Picture below shows interception of

FTP traffic using Cain and Abel, a program which allows acquiring various kinds of

passwords by sniffing the network.

Figure 65: Cain and Abel sniffing FTP credential

Upgrade or replace these protocols to their secure counterparts, FTP can be replaced by

SFTP, HTTP can be upgraded using SSL certificate (HTTPS), and Telnet can be replaced by

SSH.


Aldo Elam Majiah

4.3 Evaluate (expert judgment)

Experts’ judgment is the next process in this research’s methodology. The author asked

opinions of several experts regarding artifacts that are used in this research or resulted from

it.

Experts’ judgment activities were conducted around June and July 2014. Six experts on either

AD or security or both fields were asked about their opinion on three artifacts. The following

artifacts are to be evaluated by expert: AD risk assessment framework and AD components,

security GPO, and threat-countermeasure pairs. The last two artifacts were the result of the

risk assessment. For details on these artifacts, please refer to appendix 7.

The expertise of the experts can be divided into two groups: experts in AD and in security

fields. Experts with ID 01, 02, and 04 are experts in AD, with additional background on risk

and audit (expert 02) and security (expert 04). Experts with ID 03, 05, and 06 are experts in

security fields. For complete references on experts’ profile, please refer to appendix 6.

The author presented the artifacts to the experts, explained the purpose of the assessment, and

then noted their opinions. These evaluations was conducted one by one, the author met each

of the experts in a separate time and then have an interview and discussion with them about

the artifacts.

The result of the evaluation by experts shows that AD risk assessment framework and AD

components do not change. There was an opinion from expert 03 to add one more

component, an “environmental related threat” component, into existing AD components. But

in the next round of evaluation, expert 04 suggested that environmental threats should not be

included in AD components.

Likewise, the security GPO also did not change. But there was a suggestion from expert 06 to

divide the security GPO into their risk level. As there was not very high countermeasure for

security GPO, it can be created as two GPO: one is security GPO for high risk

countermeasure and the other is security GPO for medium risk threats.

On the other hand, the list of threat-countermeasure pairs changed much. Six new threat-

countermeasure pairs were added by the experts and eight countermeasures were added to

thwart existing threats. Experts suggested that there were previously unlisted threats that

should be added to the threat list as they directly or indirectly threatens AD or its

environment. Similarly, eight countermeasures were suggested to be added since the current

countermeasures might not be sufficient to thwart the related threats.

4.4 Observation

It has been observed from experts’ opinion that AD risk assessment framework, AD

components, and security GPO do not change as threat-countermeasure pairs. Threat and


Aldo Elam Majiah

countermeasure pair changes significantly in accordance to the expert’s expertise. Much of

the new threats, and their countermeasures, are revealed during expert judgment discussions.

This could be because the natures of threats of a system are ever increasing, and so is the

knowledge to identify these threats and how to create countermeasures for them.

Risk assessment framework and AD components used as theoretical framework in this

research is not changed, as shown in the figure 67 below. There are 7 steps in risk assessment

framework. The AD risk assessment framework steps are: AD system characterization, threat

sources and events identification, identification of vulnerability, determination of likelihood

of occurrence, determination of impact magnitude, risk determination, and the last step is

countermeasure recommendation.

Figure 66: Final AD risk assessment framework

These AD risk assessment steps are to be performed in 6 AD components. These components

are AD design & boundary, AD management, policy implementation, security of AD

computer members, security of network, and security of DC.

Figure 67: Final AD components


Aldo Elam Majiah

The assessment on the organization’s AD environment shows the following results of risk

level: 5 very high, 21 high, 79 moderate, 86 low, and 30 very low risks.

Figure 68: Risk assessment results (moderate risk level and up)

Out of these risks results, only risk with moderate level and up are treated. Low and very low

risks are considered accepted. The organization currently does not have any standard for risk

assessment, so it is assumed that the risk appetite and culture of the organization are already

integrated in the risk calculation process.

The countermeasure recommendation results have two forms: a set of security GPO

countermeasures and a list of threat-countermeasure pair as shown in subchapter 3.3.1.

During expert judgment, the security GPO is not modified by experts. There is only a note

suggesting that these GPO may not be suitable for all AD environments.

GPO countermeasures implementation can be categorized into two risk levels: high and

medium. High risk GPO countermeasures are for securing high risk threats, and medium

GPO is for medium risk threats. The implementation of high risk level GPOs consists of a set

of settings for password policies, limiting access for accounts with blank passwords, and

disabling storage of LAN Manager password hash.

5

21

79

0

10

20

30

40

50

60

70

80

90

VERY HIGH HIGH MODERATE

Risk assessment results


Aldo Elam Majiah

Figure 69: Implementation of high risk GPO countermeasures

While medium GPO countermeasures consists of implementation of account lockout policies,

Kerberos policies, audit policies, several user rights assignments, and most of security

options.

Figure 70: Implementation of medium risk GPO countermeasures (1)


Aldo Elam Majiah




Aldo Elam Majiah

The threat and countermeasure pair list, on the other hand, is modified based on experts’

knowledge. The final countermeasures for the organization’s AD environment are shown in

the following table. Countermeasures with Orange background are medium risk-level

countermeasures, bright red background categorize high risk countermeasures, and dark red

background shows they were countermeasures for very high risk threats. Countermeasures

without background color are the ones found during discussions with the experts. These

countermeasures are also categorized further in accordance to people, process, and

technology.

Table 11: Final countermeasures and their categories

Countermeasure Categories

People Process Technology

Create documentation on AD; the document should include deployment, configuration, structure, and policy guide. And it should be approved by management and controlled.

√ √

Upgrade domain and forest functional level to highest level possible to access more secure AD domain configuration. √

Create secondary domain controller.

√

Create and utilize computer-based OU in accordance to their computer functions, for example server OU, teachers' workstation OU, library computers OU, etc. √ √

Limit & control the use of high privilege domain accounts.

√

Utilize the use of restricted group to groups / accounts and minimize the use of domain admins groups for performing daily tasks √ √

Create a separate accounts to be used by administrators. One for doing daily, office-related, tasks and the other one is for managing domain. √

Implement a more secure password policy for local users.

√ Implement a more secure password policy for domain users.

√ Implementation of dual custody

√ √

Implement more secure account lockout policy.

√

Utilize log monitoring software and perform regular check on AD logs, specially on logon attempts log events and security event logs. √ √ √

Enable DNS logging

√

Perform regular backup on AD, create documents on AD backup, and test the backup result regularly. √ √ √

Implement an automatic patch management system. Monitor the patch management system regularly to ensure all domain computers are patched.

√

Assign and train administrators to monitor and elimnate incomplete patches √ √

Perform regular vulnerability assessment in accordance to organization's policy (e.g. once a year) to identify unnecessary ports, protocols, services. √


Aldo Elam Majiah

Countermeasure Categories

People Process Technology

Implement IPS for detecting network attack. √

Static ARP implementation

√ Impement DHCP snooping

√ Securing switch physical access

√ √

Upgrade to secure protocols.

√ Create a policy and standard about which applications are permitted on workstations and servers (application whitelist).

√

Implement network traffic whitelisting using application-based firewall.

√ Minimizing surface attack

√

Uninstall unnecessary ports and services.

√ Create a policy / standard for basic security hardening for workstations and servers deployment. Implement and control the policy.

√

Ensure that anti-virus were deployed correctly to all domain computers.

√

Ensure anti-virus pattern are updated in all domain computers

√

Disable booting from portable / removeable media from BIOS. Protect BIOS with password. √

Enabled host-based firewall implementation via GPO to ensure uniform implementation of firewall throughout the domain.

√

Conduct users' awareness program or training on IT security. √

Create and implement classifcation of information

√

Create a well segregated network. Server and workstations should have separated VLAN. Management network and out of band VLAN should only be accessible for the administrators. √ √

Enable biometric-based locks and monitor in/out logs.

√ Encrypt sensitive information.

√

Implement a correct audit policy to help in investigating a security incidents case.Which part of audit policy that should be enabled usually depends on the organization's policy. At least audit of success and failure of authentication of account logon events must be enabled.

√

Develop IT security policy which include acceptable use of workstations, internet, email, etc. √ Develop SDLC policy and intergrate security concerns in SDLC.

√

Implement DLP solution

√

Screensaver implemented, protected with password

√


Aldo Elam Majiah

Out of all 41 countermeasures listed in table 11, 15 countermeasures are technical in nature

and they have been tested in prototyping phase to see if they are implementable and effective.

The prototyping phase is conducted using real replica of the organization’s AD in a virtual

environment. The rest of the countermeasures cannot be tested in a short time or by using

virtual environment. Countermeasures tested in prototyping phases are:

1. Disable booting from alternative OS

2. Upgrade to higher domain and forest functional level

3. Create secondary DC

4. Create computer-based OU

5. Limit & control high privilege domain accounts

6. Utilize the use of restricted groups

7. Separate account for administrators

8. Implement secure password policies

9. Implement secure account lockout policies

10. Perform regular AD backup

11. Automatic patch management system

12. Perform regular vulnerability assessment

13. Uninstall unnecessary ports and services

14. Create AD documentation

15. Upgrade to secure protocols

Countermeasures resulted from risk assessment process are tailored specifically for AD

implementation in the assessed organization. These countermeasures may not be suitable if

they are used in other organization’s AD since result of risk assessment will be different from

one AD to another. This is the actual strong point of countermeasures resulted from this

framework, that they are specifically designed for a particular environment.


Aldo Elam Majiah

CHAPTER 5 – CONCLUSION

5.1 Conclusion

This master thesis focuses to find security countermeasure for AD, a ubiquitous system found

in almost all enterprises. In order to does this, this thesis create a risk assessment approach to

find countermeasure for AD threats.

Countermeasures resulted from the risk assessment process are specifically tailored for the

AD environment of the organization being assessed. This is the actual strong point of

countermeasures resulted from this framework, that they are specifically designed for a

particular environment. There are many guidelines, books, or best practice for securing AD.

But these books, guidelines, or best practice may not be suitable for AD implementation in an

organization since not all organizations suffer from the same threats. Using AD risk

framework as described in this research, not only an organization will be able to find out

which countermeasures should be implemented, but also it will also know which of them

should be implemented first since these countermeasures are categorized into their risk level.

The evaluation from experts shows that AD risk framework and AD components do not

change, which means it could be used to evaluate other AD environment. Nevertheless, the

list of threat events and their countermeasures are changing and evolving. Almost all of the

experts have new knowledge on AD related threats and their countermeasures, which are not

listed yet in the threat event list. This may be caused by the fact that threats are always

increasing, and so are the knowledge to countermeasure them.

Therefore, within this master thesis, it was shown that the problem of insecure

implementation of AD and its environment can be addressed using risk assessment approach.

Specific threats on an organization’s AD and the recommended countermeasures were

identified in well-structured processes, which can be performed in accordance to the

developed framework.

5.2 Recommendations

It was recommended for the organization where AD implementation being assessed to

implement countermeasures as soon as possible, especially countermeasures for high and

very high risks.

For organizations that are planning to assess their AD security using the framework used in

this research, it is recommended to perform the risk assessment processes by experienced

personnel or consultants that have exposures in both Active Directory and security field. The

result of a risk assessment may differ from one another depends on the knowledge on the

ones who perform it.


Aldo Elam Majiah

For AD security administrators who are managing AD daily, cautions must be used when

implementing a security GPO. It is best to test first a security GPO in a group of users or

computers before widely implementing it in a domain.

5.3 Future works

Evaluation by experts showed that there were still unlisted threats and countermeasures. This

is expected since the nature of threats and countermeasures are ever evolving. New threats to

AD or other systems are generated in daily basis but so are the technology and method to

counter these threats. This fact could be the limitation of this research. In a sense, the threat

list is only valid if it is updated regularly. If it is not regularly updated then the list could not

reflect newer threats or, on the contrary, the threats are becoming obsolete.

List of threat events (appendix 3) can be improved by adding new threats or deleting

irrelevant old threats from the list. This threats list is one of the strength provided by this

framework. Hence, an updated list of threat events could prove extremely useful in the search

of finding countermeasures for AD threats.

One way to improve the list of threats, and the countermeasures associated with it, is to

perform expert crowdsourcing on the AD threat list. Using expert crowdsourcing, a more

comprehensive list of threats or countermeasures could be acquired by soliciting

contributions from a large group of experts, especially from an online community. The idea

of expert crowdsourcing on a particular topic is not a new idea. For example, the MITRE

corporation (http://www.mitre.org) has been using expert crowdsourcing for developing its

CWE (common weakness enumeration), a comprehensive list of weakness on web

applications.

The future work encompasses further use of the developed framework for other AD systems.

Testing similar approach on other AD environment could prove or even enhanced the AD

risk framework, AD components, key activities, and the threat events list. Directly

implementing the result of the assessment in an AD environment and then re-do the

penetration testing processes could also prove the effectiveness of the countermeasures.

The integration of AD risk assessment concept into organization or enterprise AD

environment should be performed to mitigate the ever increasing AD-related security threats.

Therefore, in the dynamic AD environments of the future, the concept of performing regular

AD risk assessment seems to be very perspective.

http://www.mitre.org/


Aldo Elam Majiah

GLOSSARY

ACL Access control list. AD Active Directory. ADDT Active directory domains and trusts. ADUC Active directory users and computers. AP Access point (for wireless connection). ARP Address Resolution Protocol. DC Domain controller (server for Active Directory). DDoS Distributed denial of service. DLP Data loss prevention. DNS Domain Name System. Domain Hierarchy of objects in a data partition that is replicated between one or more domain controllers. DoS Denial of service. DS Design Science. DSRP Design Science Research Process.


Aldo Elam Majiah

FAIR Factor Analysis for Information Risk. Forest Collection of data partitions and domains. FSMO Flexible Single Master Operation Roles. GPO Group Policy Objects in Active Directory are a set of defined rules for settings about the user environment or the operating environment for a particular PC. IE Internet Explorer.

IS Information system. LDAP Lightweight Directory Access Protocol. OS Operating system (Windows, Linux, etc.). OU Organizational Unit. The primary type of container that is created to house objects is called an organizational unit. MITM Man in the middle.

Namespace A defined area where standardized names can be used to symbolically represent some type

of information or data (such as an IP address) and that can be resolved to the object itself.

PDC Primary domain controller. PIC Person in charge (of the system). RID Relative identification.


Aldo Elam Majiah

Sites AD representation of network location. Sites give a very unique and well-designed approach to separate specific locations within your Active Directory. Trust An agreement between two domains or forests to allow security principals (i.e., users, groups, and computers) from one domain or forest to access resources in the other domain or forest. VPN Virtual private network. WINS Windows Internet Name Service. WPAD Web Proxy Autodiscovery Protocol. WSUS Windows Server Update Services


Aldo Elam Majiah

REFERENCES

Alan R. Hevner, e. a., 2004. Design Science in Information System Research, s.l.: MIS

Quarterly.

Ammann, R. a. P., 2000. Using Model Checking to Analyze Network Vulnerabilities, s.l.: s.n.

Asha. N, e. a., 2012. Preventing SQL Injection Attacks, s.l.: International Journal of

Computer Applications.

Barnard, e. a., 2006. Why It Is Important to Audit Your Active Directory?, s.l.: Genesis

RKeyTec.

Bertino Bruschi, e. a., 2005. THREAT MODELLING FOR SQL SERVERS, Designing a

Secure Database in a Web Application, West Lafayette, IN, USA: CERIAS, Purdue

University.

Beth Sheresh, D. S., 2002. Understanding Directory Services, s.l.: System Research

Corporation.

Brian Desmond, e. a., 2013. Active Directory, s.l.: O'Reilly.

Center for Strategic and International Studies, 2013. Critical Controls for Effective Cyber

Defense, s.l.: SANS.

Chadwick, D., 2005. Threat Modelling for Active Directory, s.l.: Communications and

Multimedia Security , IFIP — The International Federation for Information Processing

Volume 175, 2005, pp 173-182 .

Chia-jung Tsui, e. a., 2010. Building an IT Taxonomy with Co-occurrence Analysis,

Hierarchical Clustering, and Multidimensional Scaling, s.l.: University of Marlyland,

iConference.

Common Criteria for Information Technology Security Evaluation, 2012. Part 3: Security

assurance components, s.l.: s.n.

D'Arcy, J. P., 2007. The Misuse of Information System: The Impact of Security

Countermeasures, s.l.: LFB Scholarly.

Defence Signals Directorate, 2012. Strategies to Mitigate Targeted Cyber Intrusions, s.l.:

Australian Government Department of Defence.

Eichstädt, R. G. a. H., 2005. THREAT MODELLING FOR ASP.NET, Designing Secure

Applications, Ilmenau: University of Technology, Ilmenau.

Farahmand, F., 2004. Developing a Risk Management System for Information Systems

Security Incidents, s.l.: Georgia Institute of Technology.


Aldo Elam Majiah

Ferrell, 1994. Discrete subjective probabilities and decision analysis: elicitation, calibration

and combination, New York: Wiley.

Hale, J. D. a. J., 2004. A Systematic Approach to Multi-Stage Network Attack Analysis, s.l.:

University of Tulsa.

Hideaki Takeda, e. a., 1990. Modelling Design Process, s.l.: AI Magazine.

Huang, Y., 2004. SCITDNS: Critical Infrastructure Protection through Secure DNS Server

Dynamic Updates, s.l.: Trusted Internet Workshop Conference.

Ihor Kuz, e. a., 2002. The Globe Infrastructure Directory Service, s.l.: Computer

Communications, Elsevier.

InformationWeek Analytics, 2011. 2011 strategic security survey, s.l.: s.n.

International Telecommunication Union, 2003. Security in Telecommunications and

Information Technology, s.l.: ITU.

ISACA, 2009. THE RISK IT PRACTITIONER GUIDE, Rolling Meadows, IL: ISACA.

ISACA, 2010. Windows Active Directory Audit/Assurance Program, s.l.: ISACA.

IT Security Firm X, 2013. Penetration testing report compendium, s.l.: s.n.

Janes, P., 2012. People, Process, and Technologies Impact on Information Data Loss, s.l.:

SANS Institute.

Ken Peffers, e. a., 2006. THE DESIGN SCIENCE RESEARCH PROCESS: A MODEL FOR

PRODUCING AND PRESENTING INFORMATION SYSTEMS RESEARCH, Claremont: s.n.

Kocis, K., 2001. Microsoft Active Directory Administration, Indiana: Sams Publishing.

Konstantinos Xynos, e. a., 2010. PENETRATION TESTING AND VULNERABILITY

ASSESSMENTS: A PROFESSIONAL APPROACH, s.l.: International Cyber Resilience

conference.

L. A. Gordon, e. a., 2006. CSI/FBI Computer Crime and Security Survey, s.l.: 11th Annual

CSI/FBI Computer Crime and Security Survey.

Lenaghan, e. a., 2007. Managing Security Threats and Vulnerabilities for Small to Medium

Enterprises, s.l.: Kingston University, IEEE International Conference on Intelligence and

Security Informatics.

Majiah, A. E., 2014. Vulnerbility scan and penetration testing document of (undisclosed

organization name), Jakarta: s.n.


Aldo Elam Majiah

Manadhata, P. K. a. J. M. W., 2011. An Attack Surface Metric, s.l.: IEEE TRANSACTIONS

ON SOFTWARE ENGINEERING.

Mark RM Talabis, J. L. M., 2013. Information Security Risk Assessment Toolkit, s.l.:

Syngress.

Mary A. Meyer, J. M. B., 2001. Eliciting and Analyzing Expert Judgment, s.l.: s.n.

Michael A. Davis, e. a., 2010. Hacking Exposed: Malware and Rootkits, s.l.: McGraw-Hill.

Michael T. Simpsons, e. a., 2011. Hands-on Ethical Hacking and Network Defense, 2nd ed.,

s.l.: Course Technology.

Microsoft, 2006. Centralized Management Component Overview, s.l.: Microsoft.

Microsoft, 2010. Technet. [Online]

Available at: http://technet.microsoft.com/en-us/library/cc787290(v=ws.10).aspx

Microsoft, 2013. Securing Active Directory: An Overview of Best Practices, s.l.: Microsoft.

Microsoft, 2014. [Online]

Available at: http://technet.microsoft.com/en-us/library/hh852345.aspx

NIST, 2002. Special Publication 800-30: Risk Management Guide for Information

Technology Systems, s.l.: National Institute of Standards and Technology.

NIST, 2008. Special Publication 800-123 Guide to General Server Security, s.l.: NIST.

NIST, 2012. NIST Special Publication 800-30 Revision 1, Gaithersburg: National Institute of

Standards and Technology.

O’Hagan, e. a., 2006. Uncertain judgments: eliciting expert probabilities, West Sussex: John

Wiley.

Osterman Research, 2010. An Osterman Research survey report, s.l.: s.n.

Oxford University Press, 2010. New Oxford American Dictionary, s.l.: s.n.

Paul Ammann, e. a., 2005. A Host–Based Approach to Network Attack Chaining Analysis,

s.l.: roceedings of the 21st Annual Computer Security Applications Conference.

Richard A. Caralli, e. a., 2007. Introducing OCTAVE Allegro: Improving the Information

Security Risk Assessment Process, s.l.: CarnegieMellon.

Robbie Allen, e. a., 2003. Active Directory, 2nd Edition., s.l.: O'Reilly.

Rommel, F., 2008. Active Directory Disaster Recovery, Birmingham: Packt Publishing.

Sakari Kouti, M. S., 2004. Inside Active Directory, 2nd ed., s.l.: Addison Wesley.


Aldo Elam Majiah

Salvatore T. March, G. F. S., 1995. Design and Natural Science Research on Information

Technology, s.l.: Elsevier.

Sandberg, S. E., 2013. Endpoint Security in the Modern Enterprise, s.l.: NTNU - Norwegian

University of Science and Technology.

Shostack, A., 2014. Threat Modelling: Designing for Security, Indianapolis: John Wiley &

Sons.

Straub, D. W., 1986. Deterring computer abuse: The effectiveness of deterrent

countermeasures in the computer security environment, s.l.: Indiana University.

Straub, D. W., 1990. Effective IS security: An empirical study. Information, s.l.: s.n.

Tankard, C., 2012. Taking the management pain out of Active Directory, s.l.: Network

Security.

The Defence Signals Directorate Australia, 2012. Top 4 Mitigations Against Cyber Intrusion:

An Implementation Guide for Project Managers, s.l.: DSD Australia.

Timothy A. Howes, e. a., 2003. Understanding and Deploying LDAP Directory Services,

Second Edition, s.l.: Addison Wesley.

Walls, J. G. e. a., 1992. Building an Information System Design, s.l.: Information Systems

Research.

Wilkins, M., 2001. Administering Active Directory, s.l.: McGraw-Hill.

Yih Huang, e. a., 2006. Closing Cluster Attack Windows Through Server Redundancy and

Rotations, Fairfax: Department of Computer Science and Center for Image Analysis.


Aldo Elam Majiah

APPENDIX

Appendix 1: AD Characterization Assessment (original forms)


Aldo Elam Majiah


Aldo Elam Majiah

Appendix 2: AD Characterization Assessment (printed)

AD characterization questions and answers

AD design & boundary:

What is the forest and domain structure? It is a single domain and single forest. There is only one domain and there are no trusts to other domain.

Please create / obtain a hierarchal diagram representation of the AD structure, starting with the forest down to domain. There is only one forest, one domain:

Is there any forest or domain trust relationship(s)? No, there is not. This is a single domain, single forest, without any relationship with other domain. If there are trust relationships, are external trusts permitted only with prior authorization? There is not any trust relationship. The organization only has one AD.

Are there appropriate administrative controls to prevent unauthorized granting of trusts? No, trusts are available because there is no other domain. Trust can only be made with higher privilege domain admin / enterprise admin / schema admin.

Do you have AD design documentation or AD policy documentation? Currently, the organization does not have any AD documentation or policy.

If there are more than one forest or domain structures; does the structure provides for a separation between service administrators? (considering administrative and security boundaries between forest/domain administrators) There is only one AD structure. Administrators are only managing this xxxjkt.com domain.

AD management

What is the domain and forest functional level? Domain functional level: Windows server 2003. Forest functional level: Windows server 2003.


Aldo Elam Majiah


Operating system on the DC: Windows server 2008.

Which server(s) hold FSMO roles? There is only one AD server. This server holds all five FSMO roles. Hostname: xxx-xxxxment IP: xxx.xxx.0.1

Please provide the domain tree structure:

Has OU deployment already aligned with organization’s structure? OU is divided into three roles of users: teachers, staff, and students. There is not any computer OU. Computer objects OU should be divided into at least servers and workstations, etc.

Has security group deployment already aligned with organization’s needs? Security groups are not deployed effectively. There were only several security groups: teachers (with 2 members), it (6 members), and student class security groups.

Who are responsible for AD? (considering personnel capabilities, workload, skills, and separation of duties) PIC responsible for AD is: Mr. H. He is also responsible for helpdesk daily job. All the administrators’ workload mainly comprise of helpdesk duties. No personnel has Microsoft certifications.

Please provide existing AD documentations (policies, logs, previous audit, etc): There is not any yet. The organization has only helpdesk log.

Are there controls for high privilege accounts groups (for example Domain Admins, Enterprise Admins, and Schema Admins groups)? No control exists yet. Personnel can create high privilege accounts on need basis. If they need it, they will create it. How they are controlled? The organization does not have any policy or change management on controlling high privilege accounts yet.

Is there delegation of tasks to groups/accounts? Delegation wizard has never been used to delegate tasks to groups/accounts.

Is there a separation of daily accounts and administrative accounts? No, there is not. High privilege accounts such as domain admins are also used for daily login to workstations and for doing daily tasks.

Are there accounts used for service, applications, or other accounts which passwords are rarely changed? Yes, install support accounts (with domain admin privilege) are used to install software in workstations. Furthermore, local administrator passwords are the same throughout the domain.

Does the organization use restricted groups feature? What for? No, the organization does not use restricted group features.

Is there a change management for AD? No, there is no change management for AD.

How do you review AD log monitoring capabilities? Do you use automated log reviewing tools? The AD logs are not monitored, and the organization does not use automated log reviewing tools yet.


Aldo Elam Majiah


What is the OS of the DC? Determine if AD functional level (forest or domain) is already the highest for DC’s operating system. The OS of the DC is Windows server 2008. The OS is higher than AD forest and domain functional level, which is 2003.

Is there a secondary DC for each site? No, there is not. There is only one site: default-first-site-name and there is only one DC xxx-xxxment.xxxjkt.com

Does the organization backup the AD? Is there a backup procedure for AD? No backup yet, and there is not any backup procedures for AD either.

Is there a periodic restore testing procedures for AD backup? Is the procedure implemented correctly? No backup restore testing for AD either.


Can GPO be deployed and implemented easily utilizing existing OU deployment? It will be hard to deploy GPO based on computers’ object because there is not OU for computer objects. All computer objects are in default computers OU, which cannot be linked to a GPO.

Review of security settings policy implementation: Account policies (password policies, account lockout policy, Kerberos policy). Password policy, Account lockout policy, and Kerberos policy:

Review of security settings policy implementation: audit policy. Audit policy is not implemented.

Review of security settings policy implementation: user rights assignments. User rights assignments policies are not implemented.

Review of security settings policy implementation: security options. Security options policies are also not implemented.

Review of security settings policy implementation: event log. Event log policies are also not configured.



Aldo Elam Majiah


Is there patch management system (patch for OS and applications)? Are patches for OS and applications set to automatically update? No WSUS sever available but all computers member are in default set to “automatically update”, yet this settings is not enforced consistently using GPO.

Does the organization have a list of application whitelist (permitted applications) to be deployed in servers and workstations? There is not application whitelist. There is not document showing application whitelisting either.

How can the use of administrative privilege be controlled? Local administrators’ passwords are only known by IT staff. But there is no control or documents describing who can use the administrative privileges locally or domain wide.

Are there secure configurations or procedures for deploying servers and workstations? (for example: disabling unrequired applications or services, patching before deploying servers or workstations). Currently there is not procedure for deploying or configuring servers or workstations.

Are anti-virus and anti-malware software correctly deployed to all servers and workstations? (check if antivirus software has been installed, determine if antivirus software can be disabled or removed, check if the signature files are updated regularly). Most of workstations and servers have their anti-virus deployed correctly. The anti-virus is updated regularly and cannot be disabled without knowing the password.

Is there a control or procedures for using removable and portable media? Currently there is not any control, technically or procedurally, for the use of USB or portable CD/DVD media.

Is there a continue vulnerability scanning processes for all AD computer members? No, currently the organization does not have vulnerability scanning process, either one time or regularly, for AD computer members.

Are data (servers’/applications’ and users’ data) backed up? Only staff and teachers data are backed up in NAS. The backup was sent regularly to holding company. Students’ data and servers’ data are not backed up.

Are default Windows firewall configured for each servers and workstations? No, default Windows firewall are not configured via GPO. Several workstations and servers have their firewall up, but most of the computers do not have their firewalls configured.

Does the organization regularly conduct users’ education program or security awareness trainings? No, there is not security awareness or training for users.

Identify whether LanMan is still used on servers/ workstations. Yes, LanMan is still used on servers/workstations. No GPO deployed for disable the use of LanMan.

Identify whether there are security-related incidents in helpdesk logs. Users are sometimes allowed to login locally if the cannot log into their computers.

Security of network

Is there a separate VLAN for users connected to wireless AP? How is the network segregation for this wireless connection? No, there is not a separate network for wireless users. Users connected to wireless will directly join to the default-first-name-site. They will part of subnet xxx.xxx.0.0/255.255.255.248.0

Review whether there are secure network configurations documents for network devices (such as firewalls, routers, and switches). There are not any network configuration documents for network devices. The switch/router in the organization is owned by ISP service provider, not by the organization.

Are network ports, protocols, and services are limited and controlled? Check this using port enumeration technique. There are insecure network protocols in used in the organization. FTP: xxx.xxx.0.100, xxx.xxx.0.220, xxx.xxx.0.221, xxx.xxx.0.222, xxx.xxx.0.254, xxx.xxx.2.254 HTTP: xxx.xxx.0.1, xxx.xxx.0.5, xxx.xxx.0.17, xxx.xxx.0.22, xxx.xxx.0.90, xxx.xxx.0.100, xxx.xxx.0.107, xxx.xxx.0.118, xxx.xxx.0.12, xxx.xxx.0.151, xxx.xxx.0.156, xxx.xxx.0.157, xxx.xxx.0.160, xxx.xxx.0.169, xxx.xxx.0.173, xxx.xxx.,.175, xxx.xxx.0.178, xxx.xxx.0.220, xxx.xxx.0.221, xxx.xxx.0.222, xxx.xxx.0.240, xxx.xxx.0.241, 192,168.0.242, xxx.xxx.0.243, xxx.xxx.0.244, xxx.xxx.0.245, xxx.xxx.0.247, xxx.xxx.0.254, xxx.xxx.1.60, xxx.xxx.1.99, xxx.xxx.1.161, xxx.xxx.2.250, xxx.xxx.2.252, xxx.xxx.2.254, xxx.xxx.3.33, xxx.xxx.3.5, xxx.xxx.3.81, xxx.xxx.3.119, xxx.xxx.5.112, xxx.xxx.6.11, xxx.xxx.6.21, xxx.xxx.6.74, xxx.xxx.7.49 Telnet:


Aldo Elam Majiah


xxx.xxx.0.220, xxx.xxx.0.221, xxx.xxx.0.222, xxx.xxx.0.241, xxx.xxx.0.242, xxx.xxx.0.244, xxx.xxx.0.254, xxx.xxx.2.254

Are there separate VLANs? How are these VLANs different from each other? Identify network segmentation / segregation. There is only one big VLAN: xxx.xxx.0.0/255.255.248.0. Currently there is no network segmentation; servers, users, teachers, students, and guests are all connected to this one VLAN.

Does the organization use network based intrusion detection / prevention system? No, the organization does not have IDS or IPS.

Does the organization use web proxy for users’ Internet connection? If yes, is there a use of website blacklisting in the proxy? The organization does not have a proxy that can function as website blacklisting device. The proxy used in the organization is a router and is connected directly to Internet.

Are cabling rooms locked with limited access and the accesses are logged? Cabling rooms are the same with server room. The room uses access control in the form of a key, the key is managed by security and IT team.

Does the organization use separate and dedicated VLAN for management ports of domain controllers and servers (RDP, SSH)? If yes, is this dedicated management network segmented from other networks and only admin workstations can connect to them? No, the organization does not have a dedicated VLAN for management ports. All users can connect directly to servers management ports using for example, SSH, RDP or Telnet.

Security of DC

Do DCs have already the latest security patches / service packs? Yes, the DC has the latest security patches and service packs as shown in below screenshot.

Are there secure configuration documentations or procedures for deploying DC? No, currently the organization does not have secure documentations or procedures for deploying DC.

Are all DCs placed in a secure physical facility (for example; a fingerprint-protected datacenter)? DC is placed in the server room (the same as cabling room). The room is not protected by biometric device but by a key. Security and IT department both have access to the key.

Are anti-virus and anti-malware software correctly deployed on DC? (Check if antivirus software has been installed, determine if antivirus software can be disabled or removed, check if the signature files are updated regularly). Yes, the DC is using anti-virus. The anti-virus is updated regularly and it cannot be disabled without a password.


Aldo Elam Majiah


Does the DC runs only essential services or features? No, the DC has many applications installed such as firebird database, file server services, and web server. The DC also functions as DNS and DHCP server.

Determine whether only authorized personnel are allowed to access DC physically. The key to server room, where the DC is placed, can be accessed by IT and security department.

Does the DC use dual power supply input? One from power line and the other is issuing a backup power supply (UPS)? Yes, the DC is using UPS (uninterruptable power supply).

Can the DC be booted using alternative OS? Yes, the DC can be booted via USB ports or DVD portable media. BIOS is also not protected by password.

Does the DC use a secure out-of-band management network? (for example; ILO for HP servers) No, the DC does not have out of band management network.


Aldo Elam Majiah

Appendix 3: List of Threat Events and Description

AD Characterization

Threat ID Threat events Threat description


Identify forest and domain structure (for example: the implemented AD is single forest, multiple domains).

T1 Forest and domain structure threats

Incorrect, hidden, forgotten, or unmanaged forest and domain structures may expose other domain/structure to threats. For example parent - child domain structure means the parent domain normally has full access to child domain. There could also some hidden, forgotten, or unmanaged domain that has access to other domains. Attacker could target these domain/forest to get into main domain.

Obtain a hierarchal diagram representation of the AD structure, starting with the forest down to domain.

T2 Forest and domain structure threats

Incorrect, hidden, forgotten, or unmanaged forest and domain structures may expose other domain/structure to threats. For example parent - child domain structure means the parent domain normally has full access to child domain. There could also some hidden, forgotten, or unmanaged domain that has access to other domains. Attacker could target these domain/forest to get into main domain.

Review of forest or domain trust relationship(s) and determine that external trusts are permitted only with prior authorization.

T3 Trust authorization threats Attacker may create a new trust if trust authorization is not controlled or trust can be created without prior authorization.

Determine whether there are appropriate administrative controls to prevent unauthorized granting of trusts.

T4 Trust authorization threats Attacker may create a new trust if trust authorization is not controlled or trust can be created without prior authorization.

Review AD design documentation.

T5 AD structure and design modification threat

Attacker may modify the structure or design of an AD undetected if there are not proper documentations for AD.

Determine if the forest or domain structure provides for a separation between service administrators, considering administrative and security boundaries between forest/domain administrators.

T6 Administrative boundary threat

Attacker (or administrator) could potentially damage AD domain (intentionally or unintentionally) if there are segregation of duties between each domain/forest administrators.

AD management

Identify domain and forest functional level.

T7 Lower functional level than OS

Domain or forest functional level might be lower than the OS of the DC(s). Functional level should be upgraded to the highest possible level whenever possible. Higher domain/forest functional level provides better security.

Identify servers holding FSMO roles.

T8 Availability of FSMO roles

The following FSMO roles should be available in a high availability for each domain: PDC emulator, RID master, Infrastructure master. The following FSMO roles should be available in a high availability for each forest: Schema master, Domain naming master.

Identify domain tree structure.

T9 AD structure and design modification threat

Attacker may modify the structure or design of an AD undetected if there are not proper documentations for AD

Determine if OU deployment has already aligned with organization’s structure.

T10 Alignment between business and AD structure

Structure of AD should be aligned with business to ease deployment of policies, software, or other related AD management issues. For example usually users and computers are separated due to the nature of GPO that can be deployed for either users or computers or both. OUs are usually represent the name of departments in the organization to ease deployment of specific software to specific departments.

Determine if security group deployment has already aligned with organization’s needs.

T11 Alignment between business and AD groups

Security groups and distribution groups should be deployed in accordance to organization's structure. For example, there should be a helpdesk security group that has access to all users' workstations.


Aldo Elam Majiah

AD Characterization


Identify the organization’s personnel responsible for AD, considering personnel capabilities, workload, skills, and separation of duties.

T12 AD PIC capabilities threats

PIC for AD should be trusted, able, and have time to manage AD. Identifying personnel responsible for AD is important to avoid unauthorized management access, accidental modification to objects, and poorly managed AD.

Review existing AD documentations (policies, logs, previous audit, etc).

T13 Proper documentation

There should be documents reviewing AD policies and procedures. Undocumented AD system (environment) could present various threats as there is not any standard for managing AD. This could lead to insecure modification of AD structure, objects, or environment.

Determine if high privilege accounts groups are controlled (for example Domain Admins, Enterprise Admins, and Schema Admins groups).

T14 High privilege account threat

High privilege accounts (domain admins, enterprise admins, schema admins, restricted groups that has access to workstations, etc.) must be limited, controlled, and logged. If an attacker could gain access as a domain admin, for example, he/she could control the entire computers and data in the AD. Restricted groups/accounts should also be identified to detect improper use of delegation task.

Review delegation of tasks to groups/accounts.


High privilege accounts (domain admins, enterprise admins, schema admins, restricted groups that has access to workstations, etc) must be limited, controlled, and logged. If an attacker could gain access as a domain admin, for example, he/she could control the entire computers and data in the AD. Restricted groups/accounts should also be identify to detect improper use of delegation task.

Review if separation of daily accounts and administrative accounts exists.

T16 Account segregation threat

Administrators or other holder of high privilege accounts should separate their daily account and the high privilege account. This separation is necessary to ensure the administrators do not perform daily tasks (browsing, doing office works) with their high privilege accounts. Whenever the administrators need to do AD management tasks, they can use "run as" feature. This separation of daily account and high privilege account for administrators could also minimize escalation privilege from high privilege account.

Identify accounts used for service, applications, or other accounts which passwords are rarely changed.

T17 Rarely changed password threat

Some accounts used in service or application uses rarely changed, or even never changed, passwords. Attacker could try to brute force all accounts with a known rarely changed passwords and find all the credentials.

Identify restricted groups. T18 High privilege account threat


Identify existing change management for AD.

T19 AD design modification Attacker may modify the structure or design of an AD undetected if there are not proper documentations for AD

Review AD log monitoring capabilities.

T20 Improper log monitoring Improper log monitoring could lead to various threats such as undetected escalation of privilege, undetected login attempt from high privilege accounts, and undetected unauthorized login into DC(s).

Determine if AD functional level (forest or domain) is already the highest for DC’s operating system.

T21 Lower functional level than OS

Domain or forest functional level might be lower than the OS of the DC(s). Functional level should be upgraded to the highest possible level whenever possible. Higher domain/forest functional level provides better security.

Review AD availability (existence of secondary / backup domain controller) for each site.

T22 Availability of AD Each site in AD should have at least two DCs for availability reasons. In case one DC fails, secondary DC can take over the role of the fail DC and provide authentication service to users.

Determine if there are backup procedures for AD.

T23 Improper implementation of AD backup

There should be a backup procedure describing backup of AD. AD should be backed up and the backup should be tested for restoration process. Retention period and backup period depend on each organization's policy.

Check whether there are periodic restore testing procedures for AD backup.




Aldo Elam Majiah

AD Characterization


Personnel security T25 Insert subverted individuals into organizations.

Adversary places individuals within organizations who are willing and able to carry out actions to cause harm to organizational missions/business functions.

T26

Insert subverted individuals into privileged positions in organizations.

Adversary places individuals in privileged positions within organizations who are willing and able to carry out actions to cause harm to organizational missions/business functions. Adversary may target privileged functions to gain access to sensitive information (e.g., user accounts, system files, etc.) and may leverage access to one privileged capability to get to another capability.


Identify whether existing OU deployment is suitable for GPO implementation.

T27 Alignment between business and AD structure

Structure of AD should be aligned with business to ease deployment of policies, software, or other related AD management issues. For example usually users and computers are separated due to the nature of GPO that can be deployed for either users or computers or both. OUs are usually represent the name of departments in the organization to ease deployment of specific software to specific departments.

Review of security settings policy implementation: Account policies (password policies, account lockout policy, Kerberos policy).

T28 Inadequate password policy implementation

Password policies must be implemented properly to ensure security of users account in the domain. Example of good password policies are: password history must be enforced to at least 10 times, maximum and minimum password age are set to at least 30 days and 1 day respectively, minimum password length are set to at least 8 character (preferable 9 if NTLM is still enabled in computers member in AD), password complexity must be set, and store password using reversible encryption must be disabled.

T29

Inadequate account lockout policy implementation

Account lockout policy must be set in way that it will minimize risk of account brute force attack and minimize mass account lockout attack. For example account lockout threshold should be set to a minimum number such as 3 times, do not set it to 0 time as it may trigger massive account lockout if a brute force attack is underway. Account lockout duration and account reset counter should be set to a agreeable amount of times defined by organization, for example 30 minutes.

Review of security settings policy implementation: audit policy.

T30 Audit policy implementation

Correct audit policy implementation help in investigating a security incidents case. Which part of audit policy that should be enabled usually depends on the organization's policy. At least audit of success and failure of authentication of account logon events must be enabled.

Review of security settings policy implementation: user rights assignments.

T31 Symbolic links threat

This privilege determines if the user can create a symbolic link from the computer he is logged on to. This privilege should only be given to trusted users. Symbolic links can expose security vulnerabilities in applications that aren’t designed to handle them.

T32 Modification of object label

This privilege determines which user accounts can modify the integrity label of objects, such as files, registry keys, or processes owned by other users. Processes running under a user account can modify the label of an object owned by that user to a lower level without this privilege.

T33 Creation of global objects

This user right is required for a user account to create global objects during Terminal Services sessions. Users can still create session-specific objects without being assigned this user right. Assigning this user right can be a security risk. Assign this user right only to trusted users.

T34

Impersonation a client after authentication

Assigning this privilege to a user allows programs running on behalf of that user to impersonate a client. Requiring this user right for this kind of impersonation prevents an unauthorized user from convincing a client to connect (for example, by remote procedure call (RPC) or named pipes) to a service that they have created and then impersonating that client, which can elevate the unauthorized user's permissions to administrative or system levels.

T35

Lack of control on who can log on through terminal services

This security setting determines which users or groups have permission to log on as a Terminal Services client. Default settings were: On workstation and servers: Administrators, Remote Desktop Users. On domain controllers: Administrators.


Aldo Elam Majiah

AD Characterization


T36

Perform volume maintenance tasks

This security setting determines which users and groups can run maintenance tasks on a volume, such as remote defragmentation. Use caution when assigning this user right. Users with this user right can explore disks and extend files in to memory that contains other data. When the extended files are opened, the user might be able to read and modify the acquired data.

T37

Enable computer and user accounts to be trusted for delegation

This security setting determines which users can set the Trusted for Delegation setting on a user or computer object. Misuse of this user right, or of the Trusted for Delegation setting, could make the network vulnerable to sophisticated attacks using Trojan horse programs that impersonate incoming clients and use their credentials to gain access to network resources.

T38

Synchronize directory service data

This security setting determines which users and groups have the authority to synchronize all directory service data. This is also known as Active Directory synchronization. Defaults: None.

T39 Deny logon locally

This security setting determines which users are prevented from logging on at the computer. This policy setting supersedes the Allow log on locally policy setting if an account is subject to both policies.

T40 Deny log on as a service

This security setting determines which service accounts are prevented from registering a process as a service. This policy setting supersedes the Log on as a service policy setting if an account is subject to both policies. Note: This security setting does not apply to the System, Local Service, or Network Service accounts. Default: None.

T41 Deny log on as a batch job

This security setting determines which accounts are prevented from being able to log on as a batch job. This policy setting supersedes the Log on as a batch job policy setting if a user account is subject to both policies. Default: None.

T42

Deny access to this computer from the network

This security setting determines which users are prevented from accessing a computer over the network. This policy setting supersedes the Access this computer from the network policy setting if a user account is subject to both policies. Default: None.

T43

Take ownership of files or other objects

This security setting determines which users can take ownership of any securable object in the system, including Active Directory objects, files and folders, printers, registry keys, processes, and threads. Assigning this user right can be a security risk. Since owners of objects have full control of them, only assign this user right to trusted users. Default: Administrators.

T44 Shut down the system

This security setting determines which users who are logged on locally to the computer can shut down the operating system using the Shut Down command. Misuse of this user right can result in a denial of service. Default on Workstations: Administrators, Backup Operators, Users. Default on Servers: Administrators, Backup Operators. Default on Domain controllers: Administrators, Backup Operators, Server Operators, Print Operators

T45

Restore files and directories

This security setting determines which users can bypass file, directory, registry, and other persistent objects permissions when restoring backed up files and directories, and determines which users can set any valid security principal as the owner of an object. Specifically, this user right is similar to granting the following permissions to the user or group in question on all files and folders on the system: Traverse Folder/Execute File and Write. Assigning this user right can be a security risk. Since users with this user right can overwrite registry settings, hide data, and gain ownership of system objects, only assign this user right to trusted users. Default: Workstations and servers: Administrators, Backup Operators. Domain controllers: Administrators, Backup Operators, Server Operators.


Aldo Elam Majiah

AD Characterization


T46

Replace a process level token

This security setting determines which user accounts can call the CreateProcessAsUser() application programming interface (API) so that one service can start another. An example of a process that uses this user right is Task Scheduler. For information about Task Scheduler, see Task Scheduler overview. Default: Network Service, Local Service.

T47

Modify firmware environment values

This security setting determines who can modify firmware environment values. Firmware environment variables are settings stored in the nonvolatile RAM of non-x86-based computers. The effect of the setting depends on the processor. On x86-based computers, the only firmware environment value that can be modified by assigning this user right is the Last Known Good Configuration setting, which should only be modified by the system. On all computers, this user right is required to install or upgrade Windows. Default: Administrators.

T48

Manage auditing and security log

This security setting determines which users can specify object access auditing options for individual resources, such as files, Active Directory objects, and registry keys. This security setting does not allow a user to enable file and object access auditing in general. For such auditing to be enabled, the Audit object access setting in Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policies must be configured. You can view audited events in the security log of the Event Viewer. A user with this privilege can also view and clear the security log. Default: Administrators.

T49 Allow log on locally

This logon right determines which users can interactively log on to this computer. Logons initiated by pressing CTRL+ALT+DEL sequence on the attached keyboard requires the user to have this logon right. Additionally this logon right may be required by some service or administrative applications that can log on users. If you define this policy for a user or group, you must also give the Administrators group this right. Default on workstations and servers: Administrators Backup Operators Users. Default on domain controllers: Account Operators Administrators Backup Operators Print Operators Server Operators.

T50 Lock pages in memory

This security setting determines which accounts can use a process to keep data in physical memory, which prevents the system from paging the data to virtual memory on disk. Exercising this privilege could significantly affect system performance by decreasing the amount of available random access memory (RAM). Default: None.

T51

Load and unload device drivers

This user right determines which users can dynamically load and unload device drivers or other code in to kernel mode. This user right does not apply to Plug and Play device drivers. It is recommended that you do not assign this privilege to other users. Assigning this user right can be a security risk. Do not assign this user right to any user, group, or process that you do not want to take over the system. Default on workstations and servers: Administrators. Default on domain controllers: Administrators Print Operators


Aldo Elam Majiah

AD Characterization


T52

Adjust memory quotas for a process

This privilege determines who can change the maximum memory that can be consumed by a process. This user right is defined in the Default Domain Controller Group Policy object (GPO) and in the local security policy of workstations and servers. Note: This privilege is useful for system tuning, but it can be misused, for example, in a denial-of-service attack. Default: Administrators Local Service Network Service.

T53 Generate security audits

This security setting determines which accounts can be used by a process to add entries to the security log. The security log is used to trace unauthorized system access. Misuse of this user right can result in the generation of many auditing events, potentially hiding evidence of an attack or causing a denial of service if the Audit: Shut down system immediately if unable to log security audits security policy setting is enabled. For more information see Audit: Shut down system immediately if unable to log security audits Default: Local Service Network Service.

T54

Force shutdown from a remote system

This security setting determines which users are allowed to shut down a computer from a remote location on the network. Misuse of this user right can result in a denial of service. This user right is defined in the Default Domain Controller Group Policy object (GPO) and in the local security policy of workstations and servers. Default: On workstations and servers: Administrators. On domain controllers: Administrators, Server Operators.

T55 Debug programs

This user right determines which users can attach a debugger to any process or to the kernel. Developers who are debugging their own applications to not need to be assigned this user right. Developers who are debugging new system components will need this user right to be able to do so. This user right provides complete access to sensitive and critical operating system components. Assigning this user right can be a security risk. Only assign this user right to trusted users. Default: Administrators

T56 Create a token object

This security setting determines which accounts can be used by processes to create a token that can then be used to get access to any local resources when the process uses an internal application programming interface (API) to create an access token. This user right is used internally by the operating system. Unless it is necessary, do not assign this user right to a user, group, or process other than Local System. Assigning this user right can be a security risk. Do not assign this user right to any user, group, or process that you do not want to take over the system. Default: None

T57 Change the system time

This user right determines which users and groups can change the time and date on the internal clock of the computer. Users that are assigned this user right can affect the appearance of event logs. If the system time is changed, events that are logged will reflect this new time, not the actual time that the events occurred. This user right is defined in the Default Domain Controller Group Policy object (GPO) and in the local security policy of workstations and servers. Default on workstations and servers: Administrators Local Service Default on domain controllers: Administrators Server Operators Local Service


Aldo Elam Majiah

AD Characterization


T58

Back up files and directories

This user right determines which users can bypass file and directory, registry, and other persistent object permissions for the purposes of backing up the system. Specifically, this user right is similar to granting the following permissions to the user or group in question on all files and folders on the system: Traverse Folder/Execute File List Folder/Read Data Read Attributes Read Extended Attributes Read Permissions Assigning this user right can be a security risk. Since there is no way to be sure that a user is backing up data, stealing data, or copying data to be distributed, only assign this user right to trusted users. Default on workstations and servers: Administrators Backup Operators. Default on domain controllers: Administrators Backup Operators Server Operators

T59

Add workstations to domain

This security setting determines which groups or users can add workstations to a domain. This security setting is valid only on domain controllers. By default, any authenticated user has this right and can create up to 10 computer accounts in the domain. Adding a computer account to the domain allows the computer to participate in Active Directory–based networking. For example, adding a workstation to a domain enables that workstation to recognize accounts and groups that exist in Active Directory. Default: Authenticated Users on domain controllers. Note: Users who have the Create Computer Objects permission on the Active Directory computers container can also create computer accounts in the domain. The distinction is that users with permissions on the container are not restricted to the creation of only 10 computer accounts. In addition, computer accounts that are created by means of Add workstations to domain have Domain Administrators as the owner of the computer account, while computer accounts that are created by means of permissions on the computers container have the creator as the owner of the computer account. If a user has permissions on the container and also has the Add workstations to domain user right, the computer is added, based on the computer container permissions rather than on the user right.

T60

Act as part of the operating system

This user right allows a process to impersonate any user without authentication. The process can therefore gain access to the same local resources as that user. Processes that require this privilege should use the Local System account, which already includes this privilege, rather than using a separate user account with this privilege specially assigned. If your organization only uses servers that are members of the Windows Server 2003 family, you do not need to assign this privilege to your users. However, if your organization uses servers running Windows 2000 or Windows NT 4.0, you might need to assign this privilege to use applications that exchange passwords in plaintext. Assigning this user right can be a security risk. Only assign this user right to trusted users. Default: None.

T61

Access this computer from the network

This user right determines which users and groups are allowed to connect to the computer over the network. Terminal Services are not affected by this user right. Default on workstations and servers: Administrators Backup Operators Users Everyone Default on domain controllers: Administrators Authenticated Users Enterprise Domain Controllers Everyone Pre-Windows 2000 Compatible Access


Aldo Elam Majiah

AD Characterization


Review of security settings policy implementation: security options.

T62 LM (LAN Manager) password hash threat

OS passwords are easier to crack if they are saved in old LM format. Password cracker could easily divide the hash and crack it separately, lead to faster password cracking execution. The use of LM password hash must be disabled throughout AD environment through the use of security options policy: "Network security: Do not store LAN Manager hash value on next password change"

T63

Recovery console: Allow automatic administrative logon

This security setting determines if the password for the Administrator account must be given before access to the system is granted. If this option is enabled, the Recovery Console does not require you to provide a password, and it automatically logs on to the system. Default: This policy is not defined and automatic administrative logon is not allowed.

T64

Devices: Restrict CD-ROM access to locally logged-on user only

This security setting determines whether a CD-ROM is accessible to both local and remote users simultaneously. If this policy is enabled, it allows only the interactively logged-on user to access removable CD-ROM media. If this policy is enabled and no one is logged on interactively, the CD-ROM can be accessed over the network. Default: This policy is not defined and CD-ROM access is not restricted to the locally logged-on user.

T65

Interactive logon: Number of previous logons to cache (in case domain controller is not available)

All previous users' logon information is cached locally so that, in the event that a domain controller is unavailable during subsequent logon attempts, they are able to log on . If a domain controller is unavailable and a user's logon information is cached, the user is prompted with a message that reads as follows: Windows cannot connect to a server to confirm your logon settings. You have been logged on using previously stored account information. If you changed your account information since you last logged on to this computer, those changes will not be reflected in this session. If a domain controller is unavailable and a user's logon information is not cached, the user is prompted with this message: The system cannot log you on now because the domain <DOMAIN_NAME> is not available. In this policy setting, a value of 0 disables logon caching. Any value above 50 only caches 50 logon attempts. Default: 10

T66

Interactive logon: Require Domain Controller authentication to unlock

Logon information must be provided to unlock a locked computer. For domain accounts, this security setting determines whether a domain controller must be contacted to unlock a computer. If this setting is disabled, a user can unlock the computer using cached credentials. If this setting is enabled, a domain controller must authenticate the domain account that is being used to unlock the computer. Default: Disabled.

T67

User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode

This security setting determines the behavior of the elevation prompt for administrators The options are: • Prompt for consent: An operation that requires elevation of privilege will prompt the Consent Admin to select either Permit or Deny. If the Consent Admin selects Permit the operation will continue with their highest available privilege. This option allows users to enter their name and password to perform a privileged task. • Prompt for credentials: An operation that requires elevation of privilege will prompt the Consent Admin to enter their user name and password. If the user enters valid credentials the operation will continue with the applicable privilege. • Elevate without prompting: This option allows the Consent Admin to perform an operation that requires elevation without consent or credentials. Note: this scenario should only be used in the most constrained environments. Default: Prompt for consent


Aldo Elam Majiah

AD Characterization


T68

User Account Control: Behavior of the elevation prompt for standard users

This security setting determines the behavior of the elevation prompt for standard users The options are: • Prompt for credentials: An operation that requires elevation of privilege will prompt the user to enter an administrative user name and password. If the user enters valid credentials the operation will continue with the applicable privilege. • Automatically deny elevation requests: This option results in an access denied error message being returned to the standard user when they try to perform an operation that requires elevation of privilege. Most enterprises running desktops as standard user will configure this policy to reduce help desk calls. Default: Prompt for credentials (home) / Automatically deny elevation requests (enterprise)

T69

Interactive logon: Do not require CTRL+ALT+DEL

This security setting determines whether pressing CTRL+ALT+DEL is required before a user can log on. If this policy is enabled on a computer, a user is not required to press CTRL+ALT+DEL to log on. Not having to press CTRL+ALT+DEL leaves users susceptible to attacks that attempt to intercept the users' passwords. Requiring CTRL+ALT+DEL before users log on ensures that users are communicating by means of a trusted path when entering their passwords. If this policy is disabled, any user is required to press CTRL+ALT+DEL before logging on to Windows (unless they are using a smart card for Windows logon). Default on domain-computers: Disabled. Default on stand-alone computers: Enabled.

T70

Interactive logon: Do not display last user name

This security setting determines whether the name of the last user to log on to the computer is displayed in the Windows logon screen. If this policy is enabled, the name of the last user to successfully log on is not displayed in the Log On to Windows dialog box. If this policy is disabled, the name of the last user to log on is displayed. Default: Disabled.

T71

Interactive logon: Message text for users attempting to log on

This security setting specifies a text message that is displayed to users when they log on. This text is often used for legal reasons, for example, to warn users about the ramifications of misusing company information or to warn them that their actions may be audited. Default: No message.

T72

Shutdown: Allow system to be shut down without having to log on

This security setting determines whether a computer can be shut down without having to log on to Windows. When this policy is enabled, the Shut Down command is available on the Windows logon screen. When this policy is disabled, the option to shut down the computer does not appear on the Windows logon screen. In this case, users must be able to log on to the computer successfully and have the Shut down the system user right before they can perform a system shutdown. Default on workstations: Enabled. Default on servers: Disabled.

T73

User Account Control: Only elevate executables that are signed and validated

This security setting will enforce PKI signature checks on any interactive application that requests elevation of privilege. Enterprise administrators can control the admin application allowed list thru the population of certificates in the local computers Trusted Publisher Store. The options are: • Enabled: Enforces the PKI certificate chain validation of a given executable before it is permitted to run. • Disabled: Does not enforce PKI certificate chain validation before a given executable is permitted to run. Default: Disabled

T74

System Cryptography: Force strong key protection for user keys stored on the computer

This security setting determines if users' private keys require a password to be used. The options are: User input is not required when new keys are stored and used User is prompted when the key is first used User must enter a password each time they use a key For more information, see Public key infrastructure.


Aldo Elam Majiah

AD Characterization


Default: This policy is not defined.

T75

Audit: Shut down system immediately if unable to log security audits

This security setting determines whether the system shuts down if it is unable to log security events. If this security setting is enabled, it causes the system to stop if a security audit cannot be logged for any reason. Typically, an event fails to be logged when the security audit log is full and the retention method that is specified for the security log is either Do Not Overwrite Events or Overwrite Events by Days. If the security log is full and an existing entry cannot be overwritten, and this security option is enabled, the following Stop error appears: STOP: C0000244 {Audit Failed} An attempt to generate a security audit failed. To recover, an administrator must log on, archive the log (optional), clear the log, and reset this option as desired. Until this security setting is reset, no users, other than a member of the Administrators group will be able to log on to the system, even if the security log is not full. Note: When configuring this security setting, changes will not take effect until you restart Windows. Default: Disabled.

T76

Network access: Do not allow storage of credentials or .NET Passports for network authentication

This security setting determines whether Stored User Names and Passwords saves passwords, credentials, or .NET Passports for later use when it gains domain authentication. If it is enabled, this setting prevents the Stored User Names and Passwords from storing passwords and credentials. Note: When configuring this security setting, changes will not take effect until you restart Windows. For more information about Stored User Names and Passwords, see Stored User Names and Passwords. Default: Disabled.

T77

Network access: Let Everyone permissions apply to anonymous users

This security setting determines what additional permissions are granted for anonymous connections to the computer. Windows allows anonymous users to perform certain activities, such as enumerating the names of domain accounts and network shares. This is convenient, for example, when an administrator wants to grant access to users in a trusted domain that does not maintain a reciprocal trust. By Default, the Everyone security identifier (SID) is removed from the token created for anonymous connections. Therefore, permissions granted to the Everyone group do not apply to anonymous users. If this option is set, anonymous users can only access those resources for which the anonymous user has been explicitly given permission. If this policy is enabled, the Everyone SID is added to the token that is created for anonymous connections. In this case, anonymous users are able to access any resource for which the Everyone group has been given permissions. Default: Disabled.


Aldo Elam Majiah

AD Characterization


T78

System cryptography: Use FIPS compliant algorithms for encryption, hashing and signing

This security setting determines if the Transport Layer Security/Secure Sockets Layer (TL/SS) Security Provider supports only the Transport Layer Security (TLS) protocol as a client and as a server (if applicable). If this setting is enabled, it uses only the Triple DES encryption algorithm for the TLS traffic encryption, only the Rivest, Shamir, and Adleman (RSA) public key algorithm for the TLS key exchange and authentication, and only the Secure Hashing Algorithm 1 (SHA-1) for the TLS hashing requirements. For Encrypting File System Service (EFS), it supports only the Triple Data Encryption Standard (DES) encryption algorithm for encrypting file data supported by the NTFS file system. By default, EFS uses the Advanced Encryption Standard (AES) algorithm with a 256-bit key in the Windows Server 2003 family and DESX algorithm in Windows XP for encrypting file data. For information about EFS, see Encrypting File System. For Terminal Services, it supports only the Triple DES encryption algorithm for encrypting terminal services network communication. For information about Terminal Services, see Terminal Services. Default: Disabled. Note: The Federal Information Processing Standard (FIPS) 140-1 is a security implementation designed for certifying cryptographic software. FIPS 140-1 validated software is required by the U.S. Government and requested by other prominent institutions.

T79

Network access: Sharing and security model for local accounts

This security setting determines how network logons using local accounts are authenticated. If this setting is set to Classic, network logons that use local account credentials authenticate by using those credentials. The Classic model allows fine control over access to resources. By using the Classic model, you can grant different types of access to different users for the same resource. If this setting is set to Guest only, network logons that use local accounts are automatically mapped to the Guest account. By using the Guest model, you can have all users treated equally. All users authenticate as Guest, and they all receive the same level of access to a given resource, which can be either Read-only or Modify. Default on domain computers: Classic. Default on stand-alone computers: Guest only

T80

Audit: Audit the use of Backup and Restore privilege

This security setting determines whether to audit the use of all user privileges, including Backup and Restore, when the Audit privilege use policy is in effect. Enabling this option when the Audit privilege use policy is also enabled generates an audit event for every file that is backed up or restored. If you disable this policy, then use of the Backup or Restore privilege is not audited even when Audit privilege use is enabled. Note: When configuring this security setting, changes will not take effect until you restart Windows. Default: Disabled.

T81

Accounts: Limit local account use of blank passwords to console logon only

This security setting determines whether local accounts that are not password protected can be used to logon from locations other than the physical computer console. If enabled, then local accounts that are not password protected will only be able to log on at the computer's keyboard. Default: Enabled.


Aldo Elam Majiah

AD Characterization


T82

Network security: LAN Manager authentication level

This security setting determines which challenge/response authentication protocol is used for network logons. This choice affects the level of authentication protocol used by clients, the level of session security negotiated, and the level of authentication accepted by servers as follows: Send LM & NTLM responses: Clients use LM and NTLM authentication and never use NTLMv2 session security; domain controllers accept LM, NTLM, and NTLMv2 authentication. Send LM & NTLM - use NTLMv2 session security if negotiated: Clients use LM and NTLM authentication and use NTLMv2 session security if the server supports it; domain controllers accept LM, NTLM, and NTLMv2 authentication. Send NTLM response only: Clients use NTLM authentication only and use NTLMv2 session security if the server supports it; domain controllers accept LM, NTLM, and NTLMv2 authentication. Send NTLMv2 response only: Clients use NTLMv2 authentication only and use NTLMv2 session security if the server supports it; domain controllers accept LM, NTLM, and NTLMv2 authentication. Send NTLMv2 response only\refuse LM: Clients use NTLMv2 authentication only and use NTLMv2 session security if the server supports it; domain controllers refuse LM (accept only NTLM and NTLMv2 authentication). Send NTLMv2 response only\refuse LM & NTLM: Clients use NTLMv2 authentication only and use NTLMv2 session security if the server supports it; domain controllers refuse LM and NTLM (accept only NTLMv2 authentication).Default: Send LM & NTLM responses on server. Undefined on workstations.

T83

Network security: Minimum session security for NTLM SSP based (including secure RPC) clients and servers

This security setting allows a client to require the negotiation of 128-bit encryption and/or NTLMv2 session security. These values are dependent on the LAN Manager Authentication Level security setting value. The options are: Require NTLMv2 session security: The connection will fail if NTLMv2 protocol is not negotiated. Require 128-bit encryption: The connection will fail if strong encryption (128-bit) is not negotiated. Default: No requirements.

T84

Network security: Do not store LAN Manager hash value on next password change

This security setting determines if, at the next password change, the LAN Manager (LM) hash value for the new password is stored. The LM hash is relatively weak and prone to attack, as compared with the cryptographically stronger Windows NT hash. Since the LM hash is stored on the local computer in the security database the passwords can be compromised if the security database is attacked. Default on Windows Vista: Enabled Default on Windows XP: Disabled.

T85

Network access: Do not allow anonymous enumeration of SAM accounts and shares

This security setting determines whether anonymous enumeration of SAM accounts and shares is allowed. Windows allows anonymous users to perform certain activities, such as enumerating the names of domain accounts and network shares. This is convenient, for example, when an administrator wants to grant access to users in a trusted domain that does not maintain a reciprocal trust. If you do not want to allow anonymous enumeration of SAM accounts and shares, then enable this policy. Default: Disabled.


Aldo Elam Majiah

AD Characterization


T86

Network access: Do not allow anonymous enumeration of SAM accounts

This security setting determines what additional permissions will be granted for anonymous connections to the computer. Windows allows anonymous users to perform certain activities, such as enumerating the names of domain accounts and network shares. This is convenient, for example, when an administrator wants to grant access to users in a trusted domain that does not maintain a reciprocal trust. This security option allows additional restrictions to be placed on anonymous connections as follows: Enabled: Do not allow enumeration of SAM accounts. This option replaces Everyone with Authenticated Users in the security permissions for resources. Disabled: No additional restrictions. Rely on default permissions. Default on workstations: Enabled. Default on server: Disabled. Important This policy has no impact on domain controllers.

T87

Network access: Remotely accessible registry paths

This security setting determines which registry paths can be accessed over the network, regardless of the users or groups listed in the access control list (ACL) of the winreg registry key. Default: System\CurrentControlSet\Control\ProductOptions System\CurrentControlSet\Control\Server Applications Software\Microsoft\Windows NT\CurrentVersion Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.

T88

Shutdown: Clear virtual memory pagefile

This security setting determines whether the virtual memory pagefile is cleared when the system is shut down. Virtual memory support uses a system pagefile to swap pages of memory to disk when they are not used. On a running system, this pagefile is opened exclusively by the operating system, and it is well protected. However, systems that are configured to allow booting to other operating systems might have to make sure that the system pagefile is wiped clean when this system shuts down. This ensures that sensitive information from process memory that might go into the pagefile is not available to an unauthorized user who manages to directly access the pagefile. When this policy is enabled, it causes the system pagefile to be cleared upon clean shutdown. If you enable this security option, the hibernation file (hiberfil.sys) is also zeroed out when hibernation is disabled on a portable computer system. Default: Disabled.

T89

System objects: Strengthen default permissions of internal system objects (e.g., Symbolic Links)

This security setting determines the strength of the default discretionary access control list (DACL) for objects. Active Directory maintains a global list of shared system resources, such as DOS device names, mutexes, and semaphores. In this way, objects can be located and shared among processes. Each type of object is created with a default DACL that specifies who can access the objects and what permissions are granted. If this policy is enabled, the default DACL is stronger, allowing users who are not administrators to read shared objects but not allowing these users to modify shared objects that they did not create. Default: Enabled.

T90

Microsoft network server: Digitally sign communications (if client agrees)

This security setting determines whether the SMB server will negotiate SMB packet signing with clients that request it. The server message block (SMB) protocol provides the basis for Microsoft file and print sharing and many other networking operations, such as remote Windows administration. To prevent man-in-the-middle attacks that modify SMB packets in transit, the SMB protocol supports the digital signing of SMB packets. This policy setting determines whether the SMB server will negotiate SMB packet signing when an SMB client requests it. If this setting is enabled, the Microsoft network server will negotiate SMB packet signing as requested by the client. That is, if packet signing has been enabled on the client, packet signing will be negotiated. If this policy is disabled, the SMB client will never negotiate SMB packet signing. Default: Enabled on domain controllers only.


Aldo Elam Majiah

AD Characterization


T91

Microsoft network server: Digitally sign communications (always)

This security setting determines whether packet signing is required by the SMB server component. The server message block (SMB) protocol provides the basis for Microsoft file and print sharing and many other networking operations, such as remote Windows administration. To prevent "man-in-the-middle" attacks that modify SMB packets in transit, the SMB protocol supports the digital signing of SMB packets. This policy setting determines whether SMB packet signing must be negotiated before further communication with an SMB client is permitted. If this setting is enabled, the Microsoft network server will not communicate with a Microsoft network client unless that client agrees to perform SMB packet signing. If this setting is disabled, SMB packet signing is negotiated between the client and server. Default: Disabled for member servers. Enabled for domain controllers.

T92

Microsoft network client: Send unencrypted password to connect to third-party SMB servers

If this security setting is enabled, the Server Message Block (SMB) redirector is allowed to send plaintext passwords to non-Microsoft SMB servers that do not support password encryption during authentication. Sending unencrypted passwords is a security risk. Default: Disabled.

T93

Microsoft network client: Digitally sign communications (if server agrees)

This security setting determines whether the SMB client attempts to negotiate SMB packet signing. The server message block (SMB) protocol provides the basis for Microsoft file and print sharing and many other networking operations, such as remote Windows administration. To prevent man-in-the-middle attacks that modify SMB packets in transit, the SMB protocol supports the digital signing of SMB packets. This policy setting determines whether the SMB client component attempts to negotiate SMB packet signing when it connects to an SMB server. If this setting is enabled, the Microsoft network client will ask the server to perform SMB packet signing upon session setup. If packet signing has been enabled on the server, packet signing will be negotiated. If this policy is disabled, the SMB client will never negotiate SMB packet signing. Default: Enabled.

T94

Microsoft network client: Digitally sign communications (always)

This security setting determines whether packet signing is required by the SMB client component. The server message block (SMB) protocol provides the basis for Microsoft file and print sharing and many other networking operations, such as remote Windows administration. To prevent man-in-the-middle attacks that modify SMB packets in transit, the SMB protocol supports the digital signing of SMB packets. This policy setting determines whether SMB packet signing must be negotiated before further communication with an SMB server is permitted. If this setting is enabled, the Microsoft network client will not communicate with a Microsoft network server unless that server agrees to perform SMB packet signing. If this policy is disabled, SMB packet signing is negotiated between the client and server. Default: Disabled.

T95

Network security: LDAP client signing requirements

This security setting determines the level of data signing that is requested on behalf of clients issuing LDAP BIND requests, as follows: None: The LDAP BIND request is issued with the options that are specified by the caller. Negotiate signing: If Transport Layer Security/Secure Sockets Layer (TLS\SSL) has not been started, the LDAP BIND request is initiated with the LDAP data signing option set in addition to the options specified by the caller. If TLS\SSL has been started, the LDAP BIND request is initiated with the options that are specified by the caller. Require signature: This is the same as Negotiate signing. However, if the LDAP server's intermediate saslBindInProgress response does not indicate that LDAP traffic signing is required, the caller is told that the LDAP BIND command request failed. If you set the server to Require signature, you must also set the client. Not setting the client results in a loss of connection with the server.


Aldo Elam Majiah

AD Characterization


T96

Domain member: Disable machine account password changes

Determines whether a domain member periodically changes its computer account password. If this setting is enabled, the domain member does not attempt to change its computer account password. If this setting is disabled, the domain member attempts to change its computer account password as specified by the setting for Domain Member: Maximum age for machine account password, which by default is every 30 days. Default: Disabled.

T97

Domain member: Digitally encrypt or sign secure channel data (always)

This security setting determines whether all secure channel traffic initiated by the domain member must be signed or encrypted. When a computer joins a domain, a computer account is created. After that, when the system starts, it uses the computer account password to create a secure channel with a domain controller for its domain. This secure channel is used to perform operations such as NTLM pass through authentication, LSA SID/name Lookup etc. This setting determines whether or not all secure channel traffic initiated by the domain member meets minimum security requirements. Specifically it determines whether all secure channel traffic initiated by the domain member must be signed or encrypted. If this policy is enabled, then the secure channel will not be established unless either signing or encryption of all secure channel traffic is negotiated. If this policy is disabled, then encryption and signing of all secure channel traffic is negotiated with the Domain Controller in which case the level of signing and encryption depends on the version of the Domain Controller and the settings of the following two policies: Domain member: Digitally encrypt secure channel data (when possible) Domain member: Digitally sign secure channel data (when possible) Default: Enabled.

T98

Domain member: Require strong (Windows 2000 or later) session key

This security setting determines whether 128-bit key strength is required for encrypted secure channel data. When a computer joins a domain, a computer account is created. After that, when the system starts, it uses the computer account password to create a secure channel with a domain controller within the domain. This secure channel is used to perform operations such as NTLM passthrough authentication, LSA SID/name Lookup, and so on. Depending on what version of Windows is running on the domain controller that the domain member is communicating with and the settings of the parameters: Domain member: Digitally encrypt or sign secure channel data (always) Domain member: Digitally encrypt secure channel data (when possible) Some or all of the information that is transmitted over the secure channel will be encrypted. This policy setting determines whether or not 128-bit key strength is required for the secure channel information that is encrypted. If this setting is enabled, then the secure channel will not be established unless 128-bit encryption can be performed. If this setting is disabled, then the key strength is negotiated with the domain controller. Default: Disabled.

T99

Domain member: Digitally encrypt secure channel data (when possible)

This security setting determines whether a domain member attempts to negotiate encryption for all secure channel traffic that it initiates. When a computer joins a domain, a computer account is created. After that, when the system starts, it uses the computer account password to create a secure channel with a domain controller for its domain. This secure channel is used to perform operations such as NTLM passthrough authentication, LSA SID/name Lookup etc. This setting determines whether or not the domain member attempts to negotiate encryption for all secure channel traffic that it initiates. If enabled, the domain member will request encryption of all secure channel traffic. If the domain controller supports encryption of all secure channel traffic, then all secure channel traffic will be encrypted. Otherwise only logon information transmitted over the secure channel will be encrypted. If this setting is disabled, then the domain member will not attempt to negotiate secure channel encryption. Default: Enabled.


Aldo Elam Majiah

AD Characterization


T100

Domain member: Digitally sign secure channel data (when possible)

This security setting determines whether a domain member attempts to negotiate signing for all secure channel traffic that it initiates. When a computer joins a domain, a computer account is created. After that, when the system starts, it uses the computer account password to create a secure channel with a domain controller for its domain. This secure channel is used to perform operations such as NTLM pass through authentication, LSA SID/name Lookup etc. This setting determines whether or not the domain member attempts to negotiate signing for all secure channel traffic that it initiates. If enabled, the domain member will request signing of all secure channel traffic. If the Domain Controller supports signing of all secure channel traffic, then all secure channel traffic will be signed which ensures that it cannot be tampered with in transit. Default: Enabled.

T101

Domain controller: LDAP server signing requirements

This security setting determines whether the LDAP server requires signing to be negotiated with LDAP clients, as follows: None: Data signing is not required in order to bind with the server. If the client requests data signing, the server supports it. Require signature: Unless TLS\SSL is being used, the LDAP data signing option must be negotiated. Default: This policy is not defined, which has the same effect as None. If you set the server to Require Signature, you must also set the client. Not setting the client results in loss of connection with the server.

T102

Network access: Allow anonymous SID/name translation

This security setting determines if an anonymous user can request security identifier (SID) attributes for another user. If this policy is enabled, a user with knowledge of an administrator's SID could contact a computer that has this policy enabled and use the SID to get the administrator's name. Default on workstations and member servers: Disabled. Default on domain controllers: Enabled.

T103

Accounts: Rename guest account

This security setting determines whether a different account name is associated with the security identifier (SID) for the account "Guest." Renaming the well-known Guest account makes it slightly more difficult for unauthorized persons to guess this user name and password combination. Default: Guest.

T104

Accounts: Rename administrator account

This security setting determines whether a different account name is associated with the security identifier (SID) for the account Administrator. Renaming the well-known Administrator account makes it slightly more difficult for unauthorized persons to guess this privileged user name and password combination. Default: Administrator.

T105

Accounts: Guest account status

This security setting determines if the Guest account is enabled or disabled. Default: Disabled. Note: If the Guest account is disabled and the security option Network Access: Sharing and Security Model for local accounts is set to Guest Only, network logons, such as those performed by the Microsoft Network Server (SMB Service), will fail.


Aldo Elam Majiah

AD Characterization


T106

Accounts: Administrator account status

This security setting determines whether the local Administrator account is enabled or disabled. Notes If you try to re-enable the Administrator account after it has been disabled, and if the current Administrator password does not meet the password requirements, you cannot re-enable the account. In this case, an alternative member of the Administrators group must reset the password on the Administrator account. For information about how to reset a password, see To reset a password. Disabling the Administrator account can become a maintenance issue under certain circumstances. For example, in a domain environment, if the secure channel that constitutes your join fails for any reason, and there is no other local Administrator account, you must restart in Safe Mode to fix the problem that is causing your join status to be broken. Under Safe Mode boot, the Administrator account is always enabled, regardless of this setting. Default: Enabled.

Review of security settings policy implementation: event log.

T107 Insufficient log monitoring capabilities

Log monitoring must be enabled throughout all AD environment. Log must be configured to be able to collect at least data from the current month to ease investigation should there be a security breach. Configure system and application log size at least 5 times of its default value and configure also security log size value to at least 10 times of its default value. Configure also log to be overwritten as the size reached its maximum size value.


Identify patch management system (patch for OS and applications).

T108 Incomplete patch threat

Patches deployment should be complete and uniform throughtout AD infrastructure. There should be patch management that control which patch should be deployed and when. Administrators should also check patch reporting console regularly and implement patches on computers that lack of them.

Identify existence of application whitelisting (permitted applications) in servers and workstations.

T109 Installation of unauthorized applications

A whitelist of applications that can be installed should be identified, documented and followed. This minimizes the risk of security breach through unauthorized applications.

T110

Insert targeted malware into organizational information systems and information system components.

Adversary inserts malware into organizational information systems and information system components (e.g., commercial or free information technology products), specifically targeted to the hardware, software, and firmware used by organizations (based on knowledge gained via reconnaissance).

Identify controlled used of administrative privilege.



Identify if there is secure configurations or procedures for deploying servers and workstations (for example: disabling unrequired applications or services, patching before deploying servers or workstations).

T112 Lack of basic security hardening

Servers and workstations, and all computers member of AD, should have basic level of hardening. There should also hardening documentation that describe the hardening process and what should be done to achieve a good hardening standard as required by the organization. Hardening usually includes disabling unrequired applications or services and patching process before deploying servers or workstations.

T113

Incorrect configuration of anti-virus

Anti-virus should be correctly configured. Correct configuration of anti-virus includes uniformly deployed of anti-virus software throughout AD environment (all AD computer members must have anti-virus deployed), antivirus software could not be able to be disabled or removed even by administrators, automatic update of signature files, and always up-to-date antivirus database and application.


Aldo Elam Majiah

AD Characterization



Patches deployment should be complete and uniform throughout AD infrastructure. There should be patch management that control which patch should be deployed and when. Administrators should also check patch reporting console regularly and implement patches on computers that lack of them.

T115

Installation of unauthorized applications

A whitelist of applications that can be installed should be identified, documented and followed. This minimize the risk of security breach through unauthorized applications.

Identify correct deployment of anti-virus and anti-malware software (check if antivirus software has been installed, determine if antivirus software can be disabled or removed, check if the signature files are updated regularly).

T116 Incorrect configuration of anti-virus


Identify removable and portable media control.

T117 Boot using alternative OS threat

DC and computer member of AD should be protected from portable bootable media via USB or CD/DVD player. If an attacker could boot a computer member from bootable media, he/she could extract password hashes from computer's SAM database and crack it using a password cracker program. If this attack is performed on DC, the attacker could gain access to all password hashes of all users in the domain.

T118 Data theft Data theft could also occur if portable media usage is not controlled.

T119

Perform malware-directed internal reconnaissance.

Adversary uses malware installed inside the organizational perimeter to identify targets of opportunity. Because the scanning, probing, or observation does not cross the perimeter, it is not detected by externally placed intrusion detection systems.

T120

Deliver malware by providing removable media.

Adversary places removable media (e.g., flash drives) containing malware in locations external to organizational physical perimeters but where employees are likely to find the media (e.g., facilities parking lots, exhibits at conferences attended by employees) and use it on organizational information systems.

Identify continues vulnerability scanning processes for AD computer members.

T121 Lack of vulnerability assessment

Regular vulnerability assessment is a in important process of securing network and overall AD computer members. This assessment helps identifies threat and vulnerability in every computers member of an AD, including its DC. Vulnerability assessment must be conducted regularly, once a year or every half a year, depend on the organization's policy. Mitigation of identified vulnerabilities must be followed afterwards.

Identify data recovery capability.



Identify whether host-based firewall is configured.

T123 Lack of host-based firewall implementation

A well configured firewall can thwart many security incidents and minimize the risk of successful exploit attacks. Firewall of all computers throughout AD environment must be configured in accordance to business needs and follow the concept of least privilege. This means only needed services pr ports are allowed to pass through the firewall.

Identify whether there users’ education and awareness.

T124 Lack of users' education on IT security

People are the weakest link in IT security. Good security awareness and education to users are essentials to build secure AD environment. Lack of security education and awareness on IT security could lead to security breach due to either users' negligence or lack of knowledge on implementing a secure daily computing activities.

Identify whether LanMan is still used on servers/ workstations.

T125 LM (LAN Manager) password hash threat

OS passwords are easier to crack if they are saved in old LM format. Password cracker could easily divide the hash and crack it separately, lead to faster password cracking execution. The use of LM password hash must be disabled throughout AD environment through the use of security options policy: "Network security: Do not store LAN Manager hash value on next password change"

Identify whether there are security-related incidents

T126 Recurring security incidents

Helpdesk log should be investigated for recurring security incidents. Security incidents must be closed and dealt properly to mitigate


Aldo Elam Majiah

AD Characterization


in helpdesk logs. recurrence.

Identify exploits and attacks

T127 Exploit physical access of authorized staff to gain access to organizational facilities.

Adversary follows (“tailgates”) authorized individuals into secure/controlled locations with the goal of gaining access to facilities, circumventing physical security checks.

T128 Exploit poorly configured or unauthorized information systems exposed to the Internet.

Adversary gains access through the Internet to information systems that are not authorized for Internet connectivity or that do not meet organizational configuration requirements.

T129 Exploit split tunneling.

Adversary takes advantage of external organizational or personal information systems (e.g., laptop computers at remote locations) that are simultaneously connected securely to organizational information systems or networks and to non-secure remote connections.

T130 Exploit known vulnerabilities in mobile systems (e.g., laptops, PDAs, smart phones).

Adversary takes advantage of fact that transportable information systems are outside physical protection of organizations and logical protection of corporate firewalls, and compromises the systems based on known vulnerabilities to gather information from those systems.

T131 Exploit recently discovered vulnerabilities.

Adversary exploits recently discovered vulnerabilities in organizational information systems in an attempt to compromise the systems before mitigation measures are available or in place.

T132 Exploit vulnerabilities on internal organizational information systems.

Adversary searches for known vulnerabilities in organizational internal information systems and exploits those vulnerabilities.

T133 Exploit vulnerabilities using zero-day attacks.

Adversary employs attacks that exploit as yet unpublicized vulnerabilities. Zero-day attacks are based on adversary insight into the information systems and applications used by organizations as well as adversary reconnaissance of organizations.

T134

Exploit vulnerabilities in information systems timed with organizational mission/business operations tempo.

Adversary launches attacks on organizations in a time and manner consistent with organizational needs to conduct mission/business operations.

T135 Compromise critical information systems via physical access.

Adversary obtains physical access to organizational information systems and makes modifications.

T136 Compromise information systems or devices used externally and reintroduced into the enterprise.

Adversary installs malware on information systems or devices while the systems/devices are external to organizations for purposes of subsequently infecting organizations when reconnected.

T137 Compromise software of organizational critical information systems.

Adversary inserts malware or otherwise corrupts critical internal organizational information systems.

T138 Compromise organizational information systems to facilitate exfiltration of data/information.

Adversary implants malware into internal organizational information systems, where the malware over time can identify and then exfiltrate valuable information.

T139 Compromise mission-critical information.

Adversary compromises the integrity of mission-critical information, thus preventing or impeding ability of organizations to which information is supplied, from carrying out operations.

T140 Conduct communications interception attacks.

Adversary takes advantage of communications that are either unencrypted or use weak encryption (e.g., encryption containing publically known flaws), targets those communications, and gains access to transmitted information and channels.

T141 Conduct wireless jamming attacks.

Adversary takes measures to interfere with wireless communications so as to impede or prevent communications from reaching intended recipients.

T142 Conduct attacks using unauthorized ports, protocols and services.

Adversary conducts attacks using ports, protocols, and services for ingress and egress that are not authorized for use by organizations.

T143 Conduct attacks leveraging traffic/data movement allowed across perimeter.

Adversary makes use of permitted information flows (e.g., email communication, removable storage) to compromise internal information systems, which allows adversary to obtain and exfiltration of sensitive information through perimeters.

T144 Conduct simple Denial of Service (DoS) attack.

Adversary attempts to make an Internet-accessible resource unavailable to intended users, or prevent the resource from functioning efficiently or at all, temporarily or indefinitely.


Aldo Elam Majiah

AD Characterization


T145 Conduct Distributed Denial of Service (DDoS) attacks.

Adversary uses multiple compromised information systems to attack a single target, thereby causing denial of service for users of the targeted information systems.

T146 Conduct targeted Denial of Service (DoS) attacks.

Adversary targets DoS attacks to critical information systems, components, or supporting infrastructures, based on adversary knowledge of dependencies.

T147 Conduct physical attacks on organizational facilities.

Adversary conducts a physical attack on organizational facilities (e.g., sets a fire).

T148 Conduct physical attacks on infrastructures supporting organizational facilities.

Adversary conducts a physical attack on one or more infrastructures supporting organizational facilities (e.g., breaks a water main, cuts a power line).

T149 Conduct brute force login attempts/password guessing attacks.

Adversary attempts to gain access to organizational information systems by random or systematic guessing of passwords, possibly supported by password cracking utilities.

T150 Conduct non-targeted zero-day attacks.

Adversary employs attacks that exploit as yet unpublicized vulnerabilities. Attacks are not based on any adversary insights into specific vulnerabilities of organizations.

T151 Conduct internally-based session hijacking.

Adversary places an entity within organizations in order to gain access to organizational information systems or networks for the express purpose of taking control (hijacking) an already established, legitimate session either between organizations and external entities (e.g., users connecting from remote locations) or between two locations within internal networks.

T152 Conduct internally-based network traffic modification (man in the middle) attacks.

Adversary operating within the organizational infrastructure intercepts and corrupts data sessions.

T153 Conduct outsider-based social engineering to obtain information.

Externally placed adversary takes actions (e.g., using email, phone) with the intent of persuading or otherwise tricking individuals within organizations into revealing critical/sensitive information (e.g., personally identifiable information).

T154 Conduct insider-based social engineering to obtain information.

Internally placed adversary takes actions (e.g., using email, phone) so that individuals within organizations reveal critical/sensitive information (e.g., mission information).

T155 Conduct attacks targeting and compromising personal devices of critical employees.

Adversary targets key organizational employees by placing malware on their personally owned information systems and devices (e.g., laptop/notebook computers, personal digital assistants, smart phones). The intent is to take advantage of any instances where employees use personal information systems or devices to handle critical/sensitive information.

T156 Obtain sensitive information via exfiltration.

Adversary directs malware on organizational systems to locate and surreptitiously transmit sensitive information.

T157 Cause degradation or denial of attacker-selected services or capabilities.

Adversary directs malware on organizational systems to impair the correct and timely support of organizational mission/business functions.

T158 Cause deterioration/destruction of critical information system components and functions.

Adversary destroys or causes deterioration of critical information system components to impede or eliminate organizational ability to carry out missions or business functions. Detection of this action is not a concern.

T159

Cause integrity loss by creating, deleting, and/or modifying data on publicly accessible information systems (e.g., web defacement).

Adversary vandalizes, or otherwise makes unauthorized changes to, organizational websites or data on websites.

T160 Cause integrity loss by polluting or corrupting critical data.

Adversary implants corrupted and incorrect data in critical data, resulting in suboptimal actions or loss of confidence in organizational data/services.

T161

Cause integrity loss by injecting false but believable data into organizational information systems.

Adversary injects false but believable data into organizational information systems, resulting in suboptimal actions or loss of confidence in organizational data/services.


Aldo Elam Majiah

AD Characterization


T162 Cause disclosure of critical and/or sensitive information by authorized users.

Adversary induces (e.g., via social engineering) authorized users to inadvertently expose, disclose, or mishandle critical/sensitive information.

T163 Cause unauthorized disclosure and/or unavailability by spilling sensitive information.

Adversary contaminates organizational information systems (including devices and networks) by causing them to handle information of a classification/sensitivity for which they have not been authorized. The information is exposed to individuals who are not authorized access to such information, and the information system, device, or network is unavailable while the spill is investigated and mitigated.

T164 Obtain information by externally located interception of wireless network traffic.

Adversary intercepts organizational communications over wireless networks. Examples include targeting public wireless access or hotel networking connections, and drive-by subversion of home or organizational wireless routers.

T165 Obtain unauthorized access.

Adversary with authorized access to organizational information systems, gains access to resources that exceeds authorization.

T166 Obtain sensitive data/information from publicly accessible information systems.

Adversary scans or mines information on publically accessible servers and web pages of organizations with the intent of finding sensitive information.

T167 Obtain information by opportunistically stealing or scavenging information systems/components.

Adversary steals information systems or components (e. g., laptop computers or data storage media) that are left unattended outside of

T168 Coordinate a campaign of multi-staged attacks (e.g., hopping).

Adversary moves the source of malicious commands or actions from one compromised information system to another, making analysis difficult.

Identify users related threats

T169 Spill sensitive information

Authorized user erroneously contaminates a device, information system, or network by placing on it or sending to it information of a classification/sensitivity which it has not been authorized to handle. The information is exposed to access by unauthorized individuals, and as a result, the device, system, or network is unavailable while the spill is investigated and mitigated.

T170 Mishandling of critical and/or sensitive information by authorized users

Authorized privileged user inadvertently exposes critical/sensitive information.

T171 Incorrect privilege settings

Authorized privileged user or administrator erroneously assigns a user exceptional privileges or sets privilege requirements on a resource too low.

T172 Communications contention

Degraded communications performance due to contention.

T173 Unreadable display Display unreadable due to aging equipment.

Identify natural threats T174 Earthquake at primary

facility Earthquake of organization-defined magnitude at primary facility makes facility inoperable.

T175 Fire at primary facility

Fire (not due to adversarial activity) at primary facility makes facility inoperable.

T176 Fire at backup facility

Fire (not due to adversarial activity) at backup facility makes facility inoperable or destroys backups of software, configurations, data, and/or logs.

T177 Flood at primary facility

Flood (not due to adversarial activity) at primary facility makes facility inoperable.

T178 Flood at backup facility

Flood (not due to adversarial activity) at backup facility makes facility inoperable or destroys backups of software, configurations, data, and/or logs.

T179 Hurricane at primary facility

Hurricane of organization-defined strength at primary facility makes facility inoperable.

T180 Hurricane at backup facility

Hurricane of organization-defined strength at backup facility makes facility inoperable or destroys backups of software, configurations, data, and/or logs.

Identify hardware related threats

T181 Resource depletion Degraded processing performance due to resource depletion.


Aldo Elam Majiah

AD Characterization


T182 Introduction of vulnerabilities into software products

Due to inherent weaknesses in programming languages and software development environments, errors and vulnerabilities are introduced into commonly used software products.

T183 Disk error Corrupted storage due to a disk error.

T184 Pervasive disk error

Multiple disk errors due to aging of a set of devices all acquired at the same time, from the same supplier.

T185 Windstorm/tornado at primary facility

Windstorm/tornado of organization-defined strength at primary facility makes facility inoperable.

WPAD poisoning

WPAD threat can potentially enables adversary to take control of others’ proxy settings and retrieve users’ credentials for that proxy. To prevent this threat, administrators could create a DNS entry for “WPAD” tha points to corporate proxy server or they can also disable AutoDetect proxy settings on IE clients altogether using GPO.

Security of network

Identify wireless AP network segregation.

T186 Insecure network segregation

Network subnetting and VLAN implementation should be deployed securely. For example, servers VLAN should be differentiated with users' VLAN and guests' VLAN to avoid users and guest from intercepting communications to/from servers. VLAN deployment should minimize the risk of MITM or relay attack (of important/sensitive communication traffic). Such attack could be perform by using, for example, ARP spoofing. Management ports for servers should also be accessible for authorized personnel only.

T187 Perform network reconnaissance/scanning.

Adversary uses commercial or free software to scan organizational perimeters to obtain a better understanding of the information technology infrastructure and improve the ability to launch successful attacks.

T188 Perform network sniffing of exposed networks.

Adversary with access to exposed wired or wireless data channels used to transmit information uses network sniffing to identify components, resources, and protections.

T189 Insert malicious scanning devices (e.g., wireless sniffers) inside facilities.

Adversary uses postal service or other commercial delivery services to deliver to organizational room a device that is able to scan wireless communications accessible from within the room and then wirelessly transmit information back to adversary.

Review whether there are secure network configurations documents for network devices (such as firewalls, routers, and switches).

T190 Insecure deployment of network devices

Network devices should be deployed securely. Network devices documentation should be created, followed, and updated regularly to ensure correct standard in network devices deployment.

Identify whether network ports, protocols, and services are limited and controlled.

T191 Minimizing surface attack

Surface attack should be minimized to mitigate attack vectors. Ports, protocols, and services should be deployed only when they are needed. Organization could perform port and service scanning, as part of regular vulnerability assessment, to confirm whether only needed ports, protocols, and services are deployed in the network.

Identify network segmentation / segregation.


Network subnetting and VLAN implementation should be deployed securely. For example, servers VLAN should be differentiated with users' VLAN and guests' VLAN to avoid users and guest from intercepting communications to/from servers. VLAN deployment should minimize the risk of MITM or relay attack (of important/sensitive communication traffic). Such attack could be perform by using, for example, ARP spoofing. Management ports for servers should also be accessible for authorized personnel only.




Adversary with access to exposed wired or wireless data channels used to transmit information, uses network sniffing to identify components, resources, and protections.

Identify the use of network based intrusion detection / prevention system.

T195 Implementation of IDS / IPS

Implementation of IPS / IDS could bring attack risks to minimum level if configured correctly. A lot of network based or exploit based attacks could be prevented by implementing IPS.


Aldo Elam Majiah

AD Characterization





Adversary with access to exposed wired or wireless data channels used to transmit information uses network sniffing to identify components, resources, and protections.

T198 Deliver known malware to internal organizational information systems (e.g., virus via email).

Adversary uses common delivery mechanisms (e.g., email) to install/insert known malware (e. g., malware whose existence is known) into organizational information systems.

T199 Deliver modified malware to internal organizational information systems.

Adversary uses more sophisticated delivery mechanisms than email (e.g., web traffic, instant messaging, FTP) to deliver malware and possibly modifications of known malware to gain access to internal organizational information systems.

Identify the use of website blacklisting in the proxy.

T200 Insecure users daily activities

Users daily activities such as browsing to the Internet, copying files to/from USB, playing CD/DVD media could bring intentional/unintentional risk to the network. Virus or malware could be unintentionally brought to organization's network by unsuspecting users.

T201 Perform malware-directed internal reconnaissance.

Adversary uses malware installed inside the organizational perimeter to identify targets of opportunity. Because the scanning, probing, or observation does not cross the perimeter, it is not detected by externally placed intrusion detection systems.

T202 Craft phishing attacks targetted for internal users

Adversary counterfeits communications from a legitimate/trustworthy source to acquire sensitive information such as usernames, passwords, or SSNs. Typical attacks occur via email, instant messaging, or comparable means; commonly directing users to websites that appear to be legitimate sites, while actually stealing the entered information.

T203 Deliver known malware to internal organizational information systems (e.g., virus via email).

Adversary uses common delivery mechanisms (e.g., email) to install/insert known malware (e. g., malware whose existence is known) into organizational information systems.

T204 Deliver modified malware to internal organizational information systems.

Adversary uses more sophisticated delivery mechanisms than email (e.g., web traffic, instant messaging, FTP) to deliver malware and possibly modifications of known malware to gain access to internal organizational information systems.

Determine if the cabling rooms and otjer ethernet cable connections are locked with limited access and the access are logged.

T205 Insecure physical data center

Data centers, cabling cabinets, and switches cabinet should be deployed securely, e.g. using locks or biometric devices, to prevent unauthorized access to both physical and logical network environment.





T208 Install general-purpose sniffers on organization-controlled information systems or networks.

Adversary installs sniffing software onto internal organizational information systems or networks.

Determine if management ports of domain controllers and servers (RDP, SSH) are connected to a dedicated management network (segmented from other networks and only admin workstations can connect to them).


Network subnetting and VLAN implementation shoiuld be deployed securely. For example, servers VLAN should be differentiated with users' VLAN and guests' VLAN to avoid users and guest from intercepting communications to/from servers. VLAN deployment should minimize the risk of MITM or relay attack (of important/sensitive communication traffic). Such attack could be perform by using, for example, ARP spoofing. Management ports for servers should also be accessible for authorized personnel only.




Aldo Elam Majiah

AD Characterization




Security of DC

Determine if all DCs have already the latest security patches / service packs.


Patches deployment should be complete and uniform throughtout AD infrastructure. There should be patch management that control which patch should be deployed and when. Administrators should also check patch reporting console regularly and implement patches on computers that lack of them.

Identity if there are secure configuration documentations or procedures for deploying DC.






Patches deployment should be complete and uniform throughout AD infrastructure. There should be patch management that control which patch should be deployed and when. Administrators should also check patch reporting console regularly and implement patches on computers that lack of them.

T216 Installation of unauthorized applications

A whitelist of applications that can be installed should be identified, documented and followed. This minimize the risk of security breach through unauthorized applications.

Check whether DC is placed in a secure physical facility.



Identify correct deployment of anti-virus and anti-malware software on DC (check if antivirus software has been installed, determine if antivirus software can be disabled or removed, check if the signature files are updated regularly).



Identify whether DC runs only essential services or features.

T219 Minimizing surface attack

Surface attack should be minimized to mitigate attack vectors. Ports, protocols, and services should be deployed only when they are needed. Organization could perform port and service scanning, as part of regular vulnerability assessment, to confirm whether only needed ports, protocols, and services are deployed in the network.



Determine whether only authorized personnel are allowed to accessed DC physically.



Determine if DC is using a backup power supply (UPS).

T222 Lack of backup power supply

Lack of UPS or similar power supply backup could present availability problem for the AD. Integrity of AD system and DC's OS could also be violated if UPS is not present.


Aldo Elam Majiah

AD Characterization


Determine if DC can be booted using alternative OS.

T223 Boot using alternative OS threat

DC and computer member of AD should be protected from portable bootable media via USB or CD/DVD player. If an attacker could boot a computer member from bootable media, he/she could extract password hashes from computer's SAM database and crack it using a password cracker program. If this attack is performed on DC, the attacker could gain access to all password hashes of all users in the domain.

Determine if DC is using a secure out-of-band management network.


Network subnetting and VLAN implementation should be deployed securely. For example, servers VLAN should be differentiated with users' VLAN and guests' VLAN to avoid users and guest from intercepting communications to/from servers. VLAN deployment should minimize the risk of MITM or relay attack (of important/sensitive communication traffic). Such attack could be performed by using, for example, ARP spoofing. Management ports for servers should also be accessible for authorized personnel only.


Aldo Elam Majiah

Appendix 4: Vulnerability Identification Table

Threat ID Vulnerability detected / identified


T1 There is no forest and domain structure threat since the domain is only single domain, single forest.

T2 There is no forest and domain structure threat since the domain is only single domain, single forest.

T3 There is no trust related threat since the domain is only single domain, single forest.

T4 There is no trust related threat since the domain is only single domain, single forest.

T5 Documentations on AD are not available, threat is imminent.

T6 There is no administrative boundary threat since the domain is only single domain, single forest.

AD management

T7 The operating system of the DC is 2008 while forest and domain functional level is 2003.

T8 There is only one DC without secondary domain controllers. All FSMO roles have availability issues.


T10 Administrators will not be able to effectively deploy applications / scripts / policies to selected computers since there is no OU for computers (for example for deploying certain security configurations to all computers in the public library).

T11 Administrators will not be able to effectively deploy applications / scripts / policies to selected security groups since security groups are not heavily used.

T12 Administrators seem too occupied with helpdesk work and spend little time in managing AD.


T14 There is no control on high privilege account threat. On the penetration testing, the pen-tester was able to get account of a domain admin.

T15 There is no delegation of tasks to groups / accounts. Daily administrative tasks were done using domain admin privilege, which is very dangerous. On the penetration testing, the pen-tester was able to get account of a domain admin.

T16 There is no separation of daily accounts and high privilege domain accounts for the administrators. Administrators were doing daily tasks such as browsing and performing office related tasks using accounts that have domain admin privilege.

T17 The passwords for local administrator accounts are all the same throughout the domain. During penetration testing, pen-tester was able to acquired one of the desktop's local administrator account and then it turns out that all computers in the domain are using the same passwords.

T18 There is no delegation of tasks to groups / accounts. Daily administrative tasks were done using domain admin privilege, which is very dangerous. On the penetration testing, the pen-tester was able to get account of a domain admin.


T20 The organization does not utilize log monitoring software. AD logs are also not monitored; pen-tester was able to acquired high privilege domain admin accounts without being detected by administrators.

T21 The operating system of the DC is 2008 while forest and domain functional level is 2003.

T22 There is only one DC without secondary domain controllers. All FSMO roles have availability issues. There is only one DC in the only site of the domain: default-first-name-site.

T23 AD is not backed up. There is no procedure for backing up AD and there is no implementation of AD backup either.


T25 HR has procedures for recruiting; the organization's vicinity is protected by security guards. Guests have to be registered to enter the organization.

T26 HR has procedures for recruiting; the organization's vicinity is protected by security guards. Guests have to be registered to enter the organization.


T27 Administrators will not be able to effectively deploy applications / scripts / policies to selected computers since there is no OU for computers (for example for deploying certain security configurations to all computers in the public library).

T28 Password policies were not adequately implemented. Minimum password length was 3 characters, password complexity was not enabled, and stored password using reversible encryption was also not set. From pen-testing report, it was discovered that: Passwords were the same as the usernames: 75 instances. 233 domain users were using “123” as the password of their accounts. 6 domain users were using “1234” as the password of their accounts. 4 domain users were using “12345” as the password of their accounts. 3 domain users were using “123456789” as the password of their accounts.


Aldo Elam Majiah


2 domain users were using “12345678” as the password of their accounts. 3 domain users were using “password” as the password of their accounts. 366 domain users were using 4 character password or less than 4 characters.

T29 The account lockout threshold is set to 0, which means all domain accounts are susceptible to mass account lockout. A hacker could launch a brute force attack and lock all accounts on AD. And administrators will enable these locked accounts one by one.

T30 Audit policy was not implemented.

T31 This policy item is not implemented. None of user right assignments policies were implemented to domain computers.





























Aldo Elam Majiah





T62 Local passwords from AD computer members are still saved in LM hash format. And so are AD users passwords saved in DC. During penetration testing, pen tester was able to found out local administrator password of AD computer members and crack 543 out of 808 domain users in less than 2 days of cracking process.

T63 This policy item is not implemented. None of security options policies were implemented to domain computers.


























T89 This policy item is not implemented. None of security options policies were implemented to domain


Aldo Elam Majiah


computers.


















T107 Log monitoring is not enabled throughout domain. Log sizes were set to its default value.


T108 Incomplete OS patches are the main problem in the domain. Six critical patches related to the following Microsoft patches: MS11-030 is missing in 8 computers, MS09-001 in 5 computers, MS08-067 in 3 computers, MS06-040 in 2 computers, MS05-027 in and MS09-050 is missing in 1 computer.

T109 There is not any list about which application that can be installed in users' workstations and servers.

T110 The likelihood of this threat is highly unlikely due to its complexity.

T111 There is no control on high privilege account threat. On the penetration testing, the pen-tester was able to get account of a domain admin.

T112 The organization does not have policy / standard for basic security hardening.

T113 Most of the anti-virus programs were deployed correctly (antivirus software could not be able to be disabled or removed even by administrators, automatic update of signature files, and always up-to-date antivirus database and application). Yet, several workstations does not have anti-virus or the anti-virus can be disabled without a password.

T114 Incomplete OS patches are the main problem in the domain. Six critical patches related to the following Microsoft patches: MS11-030 is missing in 8 computers, MS09-001 in 5 computers, MS08-067 in 3 computers, MS06-040 in 2 computers, MS05-027 in and MS09-050 is missing in 1 computer.



T117 All computers in the domain (including DC and computers in public area, such as library) can be booted using alternative OS. This enables the pen-tester to get hash passwords of a local public computer and crack the passwords.

T118 Portable media was not controlled. Data theft is possible. But data in the domain in not important (no data about salary, for example)


Aldo Elam Majiah


T119 It is highly unlikely there will be adversaries that perform such threat. The premise is guarded by security guards and all guests are controlled.


T121 The organization does not have regular vulnerability assessment, and it also never perform vulnerability assessment prior to this pen-test project.


T123 Some domain computers (workstation or servers) have their firewall up and running. But almost all of the domain computers do not have their firewall enabled and configured.

T124 There has never been users' awareness or training on IT security.


T126 From helpdesk logs, pen-tester found out that users are sometimes given local administrator access when she/he cannot logon to domain.


T128 All public facing servers are managed by vendor in a collocation program. None of the public-facing application connects directly to internal organization.

T129 There is only one location in the premise. No VPN access or other remote access to other location.

T130 Mobile systems are not allowed access to AD domain. Furthermore, there is not any outside system that connects back to the organization.

T131 A recently discovered exploit needs expertise to be launch. It is unlikely internal personnel choose to perform such threat because there are still many other simple security holes that can be exploited.

T132 During penetration testing, pen-tester was able to successfully launch several exploits on Windows OS to gain access to several workstations.


T134 It is unlikely adversaries choose to perform such threat because there are still many other simple security holes that can be exploited.


T136 There is only one location in the premise. No VPN access or other remote access to other location. Only teachers could perform such attack as they bring their laptops home, and it is unlikely that teachers will do such attack as they are highly filtered during recruitment process.

T137 Only staffs could perform such attack as they bring their laptops home, and it is unlikely that staffs will do such attack as they are highly filtered during recruitment process.

T138 It is unlikely adversaries choose to perform such threat because there are still many other simple security holes that can be exploited.

T139 As the AD is not connected to mission-critical information system (such as payroll system), it is unlikely that this threat occurs.

T140 It is possible to perform interception as demonstrated during pen-test. The organization still operates insecure protocols hence ease the implementation of interception attacks.

T141 It is highly likely there will be adversaries that conduct such attack because the adversaries must be near or inside the premise. The premise is guarded by security guards and all guests are controlled.

T142 There is no policy governing which ports, protocols, or services are authorized.

T143 All public facing servers are managed by vendor in a collocation program. None of the public-facing application connects directly to internal organization. Security of the public facing servers are managed by partner organization





T148 It is highly unlikely there will be adversaries that perform such threat. The premise is guarded by security


Aldo Elam Majiah


guards and all guests are controlled.

T149 During penetration testing, pen-tester was able to successfully launch brute force attack on domain controllers and acquired a weak password of a domain admin (highest privilege account on the AD).


T151 There is only one location in the premise. No VPN access or other remote access to other location. Only teachers could perform such attack as they bring their laptops home, and it is unlikely that teachers will do such attack as they are highly filtered during recruitment process.

T152 Pen-tester performed such attack undetected during penetration testing.

T153 Adversaries could gain information from social media such as LinkedIn and Facebook as most of the staffs, teachers, and students have their own social media.


T155 Personal owned devices are allowed but cannot connect directly to AD. Adversaries that launched such attack may target personal information (credit cards, internet banking credential) not to get inside the AD of the organization.

T156 Personal owned devices are allowed but cannot connect directly to AD. Adversaries that launched such attack may target personal information (credit cards, internet banking credential) not to get inside the AD of the organization.

T157 This threat, even though possible, is unlikely to be directed to AD of the organization.

T158 It is highly unlikely there will be internal adversaries that perform such threat. The premise is guarded by security guards and all guests are controlled, hence external adversaries are also not very possible to launch such attack.

T159 This threat could be possible, but the impact is minimum since publicly accessible information was handled by third party (partner).





T164 It is highly likely there will be adversaries that conduct such attack because the adversaries must be near or inside the premise. The premise is guarded by security guards and all guests are controlled.

T165 During penetration testing, pen-tester was able to get unauthorized access to all domain computers via compromising AD. It is likely that adversaries will be able to do the same.

T166 During pen-test, several sensitive information can be acquired from public websites, including traffic information to/and from the organization.

T167 Laptop is protected by passwords but the BIOS are not password protected. Adversary could boot the laptop and steal data using alternative OS booting.

T168 Only internal staffs and students could perform such attack as they bring their laptops home, and it is unlikely that they will do such attack.

T169 Currently the organization does not have classification of information. The attack is possible, for example due to negligence.

T170 Currently the organization does not have classification of information. The attack is possible, for example due to negligence.

T171 During penetration testing, pen-tester found account used to install software in computer with domain admin privilege. This account does not bind to any username so no one is accountable for it. Such account should not exist.

T172 This threat is unlikely to affect AD.

T173 This threat is unlikely to affect AD. Hardware in the premises was less than 3 years old.

T174 There has never been major earthquake in the city.

T175 The organization has their own anti-fire utilities.

T176 The organization does not have a backup facility.

T177 There has never been flood in the vicinity


T179 There has never been a hurricane in the country.


T181 Hardware in the organization is relatively new, less than 3 years of age. Resource depletion is unlikely to happen.


Aldo Elam Majiah


T182 The organization used much free software with little or no support.

T183 Hardware in the organization is relatively new, less than 3 years of age. Hardware error is possible but rare.

T184 Hardware in the organization is relatively new, less than 3 years of age. Hardware error is possible but rare.

T185 There has never been a windstorm/tornado in the country.

Security of network T186 The network is not segregated at all. Users from public areas and Wireless users can gain access to servers or

AD domain as the VLAN is only one.

T187 Pen-tester performed such attack undetected during penetration testing. It went undetected.

T188 Pen-tester performed such attack undetected during penetration testing of the organization's wireless network. It went undetected.

T189 It is possible although unlikely an adversary could perform such attack. To perform such attack the adversaries must first goes into the organization and passing the security guards in the premise.

T190 There is no document for deploying network devices but pen-tester did not find unsecure network devices during penetration testing.

T191 Ports, protocols, and services are not controlled. This enables a wide surface attack. Services that are not necessary should not be installed.

T192 The network is not segregated at all. Users from public areas and Wireless users can gain access to servers or AD domain as the VLAN is only one.



T195 No IDS or IPS deployed in the network.



T198 Anti-virus software was deployed correctly in almost all users' computer. This minimizes the impact of a virus spread.

T199 Anti-virus software was deployed correctly in almost all users' computer. This minimizes the impact of a malware spread.

T200 There has never been users' awareness or training on IT security.


T202 Anti-virus software was deployed correctly in almost all users' computer. This minimizes the impact of a malware spread. But users have never been trained in security awareness. This threat is not directly related to AD since the email address was not based on AD.



T205 Too many personnel are allowed to access data center. In/out logs are not managed. Data center is not protected by biometric device but by a key instead.



T208 It is possible to install a sniffer in the network since there are many public areas with unprotected Ethernet outlet.

T209 The network is not segregated at all. Users from public areas and Wireless users can gain access to servers or AD domain as the VLAN is only one.



Security of DC

T212 DC was well patched.

T213 The organization does not have policy / standard for basic security hardening. There were unnecessary applications / functions that are not supposed to be installed on the DC, such as file server, web server, firebird database.

T214 The DC has anti-virus software configured correctly (antivirus software could not be able to be disabled or removed even by administrators, automatic update of signature files, and always up-to-date antivirus database and application). Yet, several workstations does not have anti-virus or the anti-virus can be disabled without a password.

T215 The DC has only MS12-020 patch missing (Microsoft Windows Remote Desktop Protocol Server Man-in-the-Middle Weakness).


Aldo Elam Majiah





T219 Ports, protocols, and services are not controlled. This enables a wide surface attack. Services that are not directly related to AD should not be installed on the DC. The management ports on the DC should be accessible by authorized personnel only.

T220 The organization does not have policy / standard for basic security hardening. But the DC was patched and hardened by default domain controller policy.


T222 UPS was present and standby to give backup power supply when necessary.


T224 The management ports on the can be accessed by all users. MITM attacks are eminent.


Aldo Elam Majiah

Appendix 5: Threat Risk-Level and Countermeasures

ID threat

Likelihood of event initiation or occurrence

Likelihood of threat event resulting in impact

Likelihood Impact Risk Countermeasure recommendation


T1 VERY LOW VERY LOW VERY LOW HIGH LOW No countermeasure necessary.




T5 HIGH MODERATE MODERATE HIGH MODERATE Create documentation on AD; the document should include deployment, configuration, structure, and policy guide. And it should be approved by management and controlled.

T6 VERY LOW VERY LOW VERY LOW VERY LOW VERY LOW No countermeasure necessary.

AD management

T7 MODERATE MODERATE MODERATE MODERATE MODERATE Upgrade domain and forest functional level to highest level possible to access more secure AD domain configuration.

T8 HIGH HIGH HIGH HIGH HIGH Create secondary domain controller.


T10 MODERATE MODERATE MODERATE MODERATE MODERATE Create and utilize computer-based OU in accordance to their computer functions, for example server OU, teachers' workstation OU, library computers OU, etc.

T11 LOW LOW LOW LOW LOW Create and utilize security groups when necessary.

T12 HIGH LOW MODERATE LOW LOW Train AD administrators in Microsoft's certification program related to AD.


T14 HIGH HIGH HIGH VERY HIGH VERY HIGH Control the use of high privilege domain account by limiting high privilege domain admins to a minimum number.

T15 MODERATE HIGH MODERATE HIGH MODERATE Utilize the use of restricted group to groups / accounts and minimize the use of domain admins groups for performing daily tasks

T16 HIGH HIGH HIGH VERY HIGH VERY HIGH Create separate accounts to be used by administrators. One for doing daily, office-related, tasks and the other one is for managing domain.

T17 HIGH HIGH HIGH HIGH HIGH Create a policy that states passwords for domain or local accounts should be changed every several days.

T18 MODERATE HIGH MODERATE HIGH MODERATE Utilize the use of restricted group to groups / accounts and minimize the use of domain admins groups for performing daily tasks

T19 HIGH MODERATE MODERATE HIGH MODERATE Create documentation on AD, the document should include deployment, conugration, structure, and policy guide. And it should be approved by management and controlled.

T20 HIGH MODERATE MODERATE MODERATE MODERATE Utilize log monitoring software and perform regular check on AD logs, specially on logon attempts log events.

T21 MODERATE MODERATE MODERATE MODERATE MODERATE Upgrade domain and forest functional level to highest level possible to access more secure AD domain configuration.


Aldo Elam Majiah

ID threat




T22 HIGH HIGH HIGH HIGH HIGH Create secondary domain controller.

T23 MODERATE MODERATE MODERATE MODERATE MODERATE Perform regular backup on AD, create documents on AD backup, and test the backup result regularly.


T25 MODERATE VERY LOW LOW MODERATE LOW Countermeasure is sufficient.

T26 MODERATE VERY LOW LOW MODERATE LOW Countermeasure is sufficient.

Policy implementation T27 MODERATE MODERATE MODERATE MODERATE MODERATE Create and utilize computer-based OU in

accordance to their computer functiions, for example server OU, teachers' workstation OU, library computers OU, etc.

T28 HIGH VERY HIGH VERY HIGH HIGH HIGH Implement a more secure password policy for domain users. Example of good password policies are: password history must be enforced to at least 10 times, maximum and minimum password age are set to at least 30 days and 1 day respectively, minimum password length are set to at least 8 character (preferable 9 if NTLM is still enabled in computers member in AD), password complexity must be set, and strore password using reversible encryption must be disabled.

T29 HIGH HIGH HIGH MODERATE MODERATE Implement better account lockout policy:For example account lockout threshold should be set to a minimum number such as 3 times, do not set it to 0 time as it may trigger massive account lockout if a bruteforce attack is underway. Account lockout duration and account reset counter should be set to a agreeable amount of times defined by organization, for example 30 minutes.

T30 MODERATE MODERATE MODERATE MODERATE MODERATE Implement a correct audit policy to help in investigating a security incidents case.Which part of audit policy that should be enabled usually depends on the organization's policy. At least audit of success and failure of authentication of account logon events must be enabled.

T31 LOW LOW LOW LOW LOW Implement this policy to the domain prudently: Symbolic links threat

T32 LOW LOW LOW LOW LOW Implement this policy to the domain prudently: Modification of object label

T33 VERY LOW LOW VERY LOW LOW VERY LOW Implement this policy to the domain prudently: Creation of global objects

T34 MODERATE MODERATE MODERATE LOW LOW Implement this policy to the domain prudently: Impersonation a client after authentication

T35 MODERATE MODERATE MODERATE MODERATE MODERATE Implement this policy to the domain prudently: Deny log on through Terminal Services

T36 VERY LOW LOW VERY LOW LOW VERY LOW Implement this policy to the domain prudently: Perform volume maintenance tasks

T37 LOW LOW LOW MODERATE LOW Implement this policy to the domain prudently: Enable computer and user accounts to be trusted for delegation


Aldo Elam Majiah

ID threat




T38 VERY LOW LOW VERY LOW LOW VERY LOW Implement this policy to the domain prudently: Synchronize directory service data

T39 LOW MODERATE LOW MODERATE LOW Implement this policy to the domain prudently: Deny logon locally

T40 LOW MODERATE LOW MODERATE LOW Implement this policy to the domain prudently: Deny log on as a service

T41 LOW MODERATE LOW MODERATE LOW Implement this policy to the domain prudently: Deny log on as a batch job

T42 MODERATE LOW LOW MODERATE LOW Implement this policy to the domain prudently: Deny access to this computer from the network

T43 LOW VERY LOW VERY LOW LOW VERY LOW Implement this policy to the domain prudently: Take ownership of files or other objects

T44 MODERATE MODERATE MODERATE MODERATE MODERATE Implement this policy to the domain prudently: Shut down the system

T45 MODERATE LOW LOW MODERATE LOW Implement this policy to the domain prudently: Restore files and directories

T46 MODERATE MODERATE MODERATE MODERATE MODERATE Implement this policy to the domain prudently: Replace a process level token

T47 VERY LOW LOW VERY LOW LOW VERY LOW Implement this policy to the domain prudently: Modify firmware environment values

T48 MODERATE LOW LOW LOW LOW Implement this policy to the domain prudently: Manage auditing and security log

T49 MODERATE MODERATE MODERATE MODERATE MODERATE Implement this policy to the domain prudently: Allow log on locally. Do not allow users to logged on to servers.

T50 MODERATE LOW LOW MODERATE LOW Implement this policy to the domain prudently: Lock pages in memory

T51 MODERATE LOW LOW LOW LOW Implement this policy to the domain prudently: Load and unload device drivers

T52 LOW VERY LOW VERY LOW LOW VERY LOW Implement this policy to the domain prudently: Adjust memory quotas for a process

T53 LOW VERY LOW VERY LOW LOW VERY LOW Implement this policy to the domain prudently: Generate security audits

T54 LOW MODERATE LOW MODERATE LOW Force shutdown from a remote Implement this policy to the domain prudently: system

T55 LOW MODERATE LOW MODERATE LOW Implement this policy to the domain prudently: Debug programs

T56 MODERATE MODERATE MODERATE MODERATE MODERATE Implement this policy to the domain prudently: Create a token object

T57 LOW MODERATE LOW MODERATE LOW Implement this policy to the domain prudently: Change the system time

T58 MODERATE MODERATE MODERATE MODERATE MODERATE Implement this policy to the domain prudently: Back up files and directories

T59 LOW MODERATE LOW LOW LOW Implement this policy to the domain prudently: Add workstations to domain

T60 LOW MODERATE LOW MODERATE LOW Implement this policy to the domain prudently: Act as part of the operating system

T61 HIGH MODERATE MODERATE MODERATE MODERATE Implement this policy to the domain prudently:Access this computer from the network. Do not assigned everyone value to these settings.

T62 HIGH HIGH HIGH HIGH HIGH Implement this policy to the domain prudently: Network security: Do not store LAN Manager hash value on next password change. This policy must be implemented domain wide.


Aldo Elam Majiah

ID threat




T63 LOW VERY LOW VERY LOW LOW VERY LOW Implement this policy to the domain prudently: Recovery console: Allow automatic administrative logon

T64 LOW LOW LOW LOW LOW Implement this policy to the domain prudently: Devices: Restrict CD-ROM access to locally logged-on user only

T65 MODERATE HIGH MODERATE HIGH MODERATE Implement this policy to the domain prudently: Interactive logon: Number of previous logons to cache (in case domain controller is not available)

T66 MODERATE MODERATE MODERATE LOW LOW Implement this policy to the domain prudently: Interactive logon: Require Domain Controller authentication to unlock

T67 MODERATE MODERATE MODERATE LOW LOW Implement this policy to the domain prudently: User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode

T68 MODERATE MODERATE MODERATE VERY LOW VERY LOW Implement this policy to the domain prudently:

T69 HIGH MODERATE MODERATE MODERATE MODERATE Implement this policy to the domain prudently: Interactive logon: Do not require CTRL+ALT+DEL

T70 LOW MODERATE LOW LOW LOW Implement this policy to the domain prudently: Interactive logon: Do not display last user name

T71 HIGH MODERATE MODERATE MODERATE MODERATE Implement this policy to the domain prudently: Interactive logon: Message text for users attempting to log on

T72 MODERATE MODERATE MODERATE LOW LOW Implement this policy to the domain prudently: Shutdown: Allow system to be shut down without having to log on

T73 LOW LOW LOW LOW LOW Implement this policy to the domain prudently: User Account Control: Only elevate executables that are signed and validated

T74 LOW MODERATE LOW LOW LOW Implement this policy to the domain prudently: System Cryptography: Force strong key protection for user keys stored on the computer

T75 HIGH MODERATE MODERATE MODERATE MODERATE Implement this policy to the domain prudently: Audit: Shut down system immediately if unable to log security audits

T76 LOW MODERATE LOW MODERATE LOW Implement this policy to the domain prudently:

T77 MODERATE HIGH MODERATE HIGH MODERATE Implement this policy to the domain prudently: Network access: Let Everyone permissions apply to anonymous users

T78 LOW MODERATE LOW MODERATE LOW Implement this policy to the domain prudently: System cryptography: Use FIPS compliant algorithms for encryption, hashing and signing

T79 LOW VERY LOW VERY LOW MODERATE LOW Implement this policy to the domain prudently: Network access: Sharing and security model for local accounts

T80 LOW LOW LOW LOW LOW Implement this policy to the domain prudently: Audit: Audit the use of Backup and Restore privilege

T81 HIGH HIGH HIGH HIGH HIGH Implement this policy to the domain prudently: Accounts: Limit local account use of blank passwords to console logon only

T82 HIGH MODERATE MODERATE MODERATE MODERATE Implement this policy to the domain


Aldo Elam Majiah

ID threat




prudently: Network security: LAN Manager authentication level

T83 MODERATE MODERATE MODERATE MODERATE MODERATE Implement this policy to the domain prudently:


T85 MODERATE LOW LOW LOW LOW Implement this policy to the domain prudently: Network access: Do not allow anonymous enumeration of SAM accounts and shares

T86 MODERATE MODERATE MODERATE MODERATE MODERATE Implement this policy to the domain prudently: Network access: Do not allow anonymous enumeration of SAM accounts

T87 LOW MODERATE LOW LOW LOW Implement this policy to the domain prudently:

T88 LOW MODERATE LOW MODERATE LOW Implement this policy to the domain prudently: Shutdown: Clear virtual memory pagefile

T89 LOW LOW LOW LOW LOW Implement this policy to the domain prudently:

T90 MODERATE MODERATE MODERATE MODERATE MODERATE Implement this policy to the domain prudently: Microsoft network server: Digitally sign communications (if client agrees)

T91 MODERATE MODERATE MODERATE MODERATE MODERATE Implement this policy to the domain prudently: Microsoft network server: Digitally sign communications (always)

T92 LOW MODERATE LOW MODERATE LOW Implement this policy to the domain prudently: Microsoft network client: Send unencrypted password to connect to third-party SMB servers

T93 MODERATE MODERATE MODERATE MODERATE MODERATE Implement this policy to the domain prudently: Microsoft network client: Digitally sign communications (if server agrees)

T94 MODERATE LOW LOW MODERATE LOW Implement this policy to the domain prudently: Microsoft network client: Digitally sign communications (always)

T95 MODERATE LOW LOW MODERATE LOW Implement this policy to the domain prudently: Network security: LDAP client signing requirements

T96 LOW LOW LOW LOW LOW Implement this policy to the domain prudently: Domain member: Disable machine account password changes

T97 MODERATE LOW LOW LOW LOW Implement this policy to the domain prudently: Domain member: Digitally encrypt or sign secure channel data (always)

T98 LOW MODERATE LOW MODERATE LOW Implement this policy to the domain prudently: Domain member: Require strong (Windows 2000 or later) session key

T99 MODERATE LOW LOW MODERATE LOW Implement this policy to the domain prudently: Domain member: Digitally encrypt secure channel data (when possible)

T100 MODERATE LOW LOW MODERATE LOW Implement this policy to the domain prudently: Domain member: Digitally sign secure channel data (when possible)

T101 LOW MODERATE LOW MODERATE LOW Implement this policy to the domain prudently: Domain controller: LDAP server signing requirements


Aldo Elam Majiah

ID threat




T102 HIGH HIGH HIGH MODERATE MODERATE Implement this policy to the domain prudently: Network access: Allow anonymous SID/name translation

T103 LOW LOW LOW LOW LOW Implement this policy to the domain prudently: Accounts: Rename guest account

T104 MODERATE MODERATE MODERATE MODERATE MODERATE Implement this policy to the domain prudently: Accounts: Rename administrator account

T105 MODERATE HIGH MODERATE MODERATE MODERATE Implement this policy to the domain prudently: Accounts: Guest account status. Disabled guest accounts whenever possible.

T106 MODERATE MODERATE MODERATE MODERATE MODERATE Implement this policy to the domain prudently: Accounts: Administrator account status.

T107 MODERATE MODERATE MODERATE MODERATE MODERATE Add log size of, at least, security events. Monitor all logs and events using a log monitoring software.


T108 HIGH HIGH HIGH VERY HIGH VERY HIGH Implement an automatic patch management system. Monitor the patch management system regularly to ensure all domain computers are patched.

T109 MODERATE HIGH MODERATE MODERATE MODERATE Create a policy and standard about which applications are permitted on workstations and servers.

T110 VERY LOW LOW VERY LOW VERY LOW VERY LOW

T111 HIGH HIGH HIGH VERY HIGH VERY HIGH Control the use of high privilege domain account by limiting high privilege domain admins to a minimum number.

T112 HIGH HIGH HIGH HIGH HIGH Create a policy / standard for basic security hardening for workstations and servers deployment. Implement and control the policy.

T113 MODERATE MODERATE MODERATE HIGH MODERATE Ensure that anti-virus were deployed correctly to all domain computers.

T114 HIGH HIGH HIGH VERY HIGH VERY HIGH Implement an automatic patch management system. Monitor the patch management system regularly to ensure all domain computers are patched.


T116 MODERATE MODERATE MODERATE HIGH MODERATE Ensure that anti-virus were deployed correctly to all domain computers.

T117 MODERATE HIGH MODERATE MODERATE MODERATE Disable booting from portable / removeable media from BIOS. Protect BIOS with password.

T118 LOW LOW LOW MODERATE LOW



T121 MODERATE HIGH MODERATE MODERATE MODERATE Perform regular vulnerability assessment in accordance to organization's policy (e.g. once a year).


T123 MODERATE HIGH MODERATE MODERATE MODERATE Enabled host-based firewall implementation via GPO to ensure uniform implementation of firewall throughout the domain.


Aldo Elam Majiah

ID threat




T124 HIGH MODERATE MODERATE MODERATE MODERATE Conduct users' awareness program or training on IT security.



T127 VERY LOW LOW VERY LOW LOW VERY LOW

T128 VERY LOW LOW VERY LOW MODERATE LOW




T132 HIGH HIGH HIGH HIGH HIGH




T136 LOW LOW LOW LOW LOW



T139 MODERATE VERY LOW LOW HIGH LOW

T140 MODERATE HIGH MODERATE HIGH MODERATE Disable insecure protocols and replace them with their secure counterparts.


T142 MODERATE HIGH MODERATE HIGH MODERATE Disable insecure protocols and replace them with their secure counterparts. Create application whitelisting.

T143 MODERATE LOW LOW MODERATE LOW




T147 LOW MODERATE LOW MODERATE LOW


T149 MODERATE VERY HIGH HIGH HIGH HIGH Implement a more secure password policy for domain users. Implement also better account lockout policy.



T152 VERY HIGH LOW MODERATE VERY HIGH HIGH Implement IDS / IPS for detecting such attack.




T156 MODERATE LOW LOW LOW LOW










Aldo Elam Majiah

ID threat




T165 MODERATE MODERATE MODERATE MODERATE MODERATE Create and implement IT policy. Include acceptable use of workstations, internet, email, etc.

T166 LOW HIGH MODERATE HIGH MODERATE Integrate security into SDLC of every software development, including web applications.

T167 LOW HIGH MODERATE HIGH MODERATE Encrypt sensitive information.


T169 HIGH MODERATE MODERATE MODERATE MODERATE Create and implement classifcation of information and conduct users' awareness on it.

T170 HIGH MODERATE MODERATE MODERATE MODERATE Create and implement classifcation of information and conduct users' awareness on it.

T171 MODERATE HIGH MODERATE VERY HIGH HIGH Control the use of high privilege domain account by limiting high privilege domain admins to a minimum number.

T172 VERY LOW LOW VERY LOW VERY LOW VERY LOW

T173 VERY LOW LOW VERY LOW LOW VERY LOW Replace hardware regularly, in accordance to organization's policy.



T176 VERY LOW VERY LOW VERY LOW VERY LOW VERY LOW






T182 LOW MODERATE LOW LOW LOW




Security of network

T186 HIGH HIGH HIGH HIGH HIGH Create a well segregated network. Server and workstations should have separated VLAN. Management network and out of band VLAN should only be accessible for the administrators.

T187 VERY HIGH LOW MODERATE HIGH MODERATE Implement IDS / IPS for detecting such attack.

T188 VERY HIGH LOW MODERATE HIGH MODERATE Implement IDS / IPS for detecting such attack.



T191 HIGH HIGH HIGH HIGH HIGH Perform regular vulnerability assessment in accordance to organization's policy (e.g. once a year) to identify unnecessary ports, protocols, services. Uninstall unnecessary ports and services. Upgrade to secure protocols.


T193 VERY HIGH LOW MODERATE MODERATE MODERATE Implement IDS / IPS for detecting such attack.


T195 MODERATE MODERATE MODERATE HIGH MODERATE Implement IDS / IPS for detecting such attack.





Aldo Elam Majiah

ID threat







T202 MODERATE MODERATE MODERATE MODERATE MODERATE Conduct users' awareness program or training on IT security.



T205 HIGH HIGH HIGH HIGH HIGH



T208 VERY HIGH LOW MODERATE MODERATE MODERATE




Security of DC


T213 HIGH MODERATE MODERATE HIGH MODERATE Create a policy / standard for basic security hardening for workstations and servers deployment. Implement and control the policy.

T214 LOW LOW LOW HIGH LOW

T215 MODERATE MODERATE MODERATE MODERATE MODERATE Implement an automatic patch management system. Monitor the patch management system regularly to ensure all domain computers are patched.


T217 HIGH HIGH HIGH HIGH HIGH Enable biometric-based locks and monitor in/out logs.

T218 LOW LOW LOW HIGH LOW



T221 HIGH HIGH HIGH HIGH HIGH Enable biometric-based locks and monitor in/out logs.

T222 VERY LOW MODERATE LOW MODERATE LOW


T224 MODERATE MODERATE MODERATE MODERATE MODERATE Create a well segregated network. Server and workstations should have separated VLAN. Management network and out of band VLAN should only be accessible for the administrators.


Aldo Elam Majiah

Appendix 6: Expert’s Profiles

Identification Expertise Expert 01 She works as solution architect in a Japanese-based system integrator company.

She has 4 years of experiences in infrastructure fields, AD, virtualization, and network implementation. She was well versed in Cisco, Microsoft, and VMWare solutions. Certifications: VMWare Certified Professional 4 & 5 HP AIS – Network Infrastructure MCITP Enterprise Administrator Cisco Certified Network Associate STS – Symantec Backup Exec Cisco Certified Design Associate

Expert 02 He has over 12 years of professional experience in positions as manager, IT auditor, IT security consultant, senior system engineer, network administrator supervisor, and system administrator. Certifications: Certified Information Systems Auditor (CISA) Certified Information Security Manager (CISM) Microsoft Certified Systems Engineer (MCSE) ISO 27001 Lead Auditor

Expert 03 He has over 12 years of professional experience in information security field and has been working on number penetration testing projects. He is currently active in several projects: OWASP Indonesia; openSUSE Indonesia; DVWA Web Applications. He also has published an international book on IT security: Kali Linux – Assuring Security by Penetration Testing. Certifications: CISSP - Certified Information Systems Security Professional Symantec STS - Control Compliance Suite and Security Information Manager ISO 27001 Lead Auditor

Expert 04 He has more than 5 years’ experience as technical consultant and delivers more than 59 projects related with Windows infrastructure, VMWare implementation, and Symantec solutions. Certifications: Certified Ethical Hacker MCITP Microsoft Exchange VCP (VMWare Certified Professional) for VMWare 5, 4, and 3 MCITP Enterprise Administrator MCTS Windows Server Virtualization MCITP Server Administrator Sun Certified System Administrator

Expert 05 As a CTO of an IT security firm, he has over 15 years of information security experience. He has delivered over 100 security consulting projects in Indonesia for reputable enterprise and government institutions. He is also experienced in conducting a security research and is an author of a several recognized security white papers on Telecom Fraud, Bluetooth, web-application security etc. He is also a frequent speaker on various regional security conferences. Certification: Certified Ethical Hacker


Aldo Elam Majiah

Identification Expertise Expert 06 He has deep experience in network and information security for enterprise and

telecommunication for mobile operators. He also has delivered consulting projects for enterprises and telco companies, including Wifi and web app pentest, vulnerability assessment, network security architecture review, and network system configuration review. Certification: CISSP (Certified Information System Security Professional) CISA (Certified Information System Auditor) ISO27001:2005 Lead Auditor SANS-GCFW (GIAC Certified Firewall Analyst) SANS-GCIH (GIAC Certified Incident Handling) Foundstone RMTP (Risk Management Technical Professional) ACSA (ArcSight Certified Security Analyst) ACIA (ArcSight Certified Integrator/Administrator) CCSP - Cisco Certified Security Professional


Aldo Elam Majiah

Appendix 7: Artifacts Evaluated by Experts

The first artifact to be evaluated by experts is AD risk assessment framework and AD

components.


Aldo Elam Majiah

The second artifact, security GPO, is the result of the risk assessment process on AD

components of the organization. Below is the security GPO.

Security_GPO Computer Configuration (Enabled) Policies Windows Settings Security Settings Account Policies/Password Policy Policy Setting

Enforce password history 10 passwords remembered Maximum password age 30 days Minimum password age 1 days Minimum password length 8 characters Password must meet complexity requirements Enabled Store passwords using reversible encryption Disabled Account Policies/Account Lockout Policy Policy Setting

Account lockout duration 30 minutes Account lockout threshold 3 invalid logon attempts Reset account lockout counter after 30 minutes Account Policies/Kerberos Policy Policy Setting

Enforce user logon restrictions Enabled Maximum lifetime for service ticket 600 minutes Maximum lifetime for user ticket 10 hours Maximum lifetime for user ticket renewal 34 days Maximum tolerance for computer clock synchronization

5 minutes

Local Policies/Audit Policy Policy Setting

Audit account logon events Success, Failure Audit account management Success, Failure Audit directory service access Failure Audit logon events Success, Failure Audit object access Failure Audit policy change Success, Failure Audit privilege use Success, Failure Audit process tracking Failure Audit system events Success, Failure Local Policies/User Rights Assignment Policy Setting

Access this computer from the network BUILTIN\Backup Operators, BUILTIN\Administrators Allow log on locally BUILTIN\Backup Operators, BUILTIN\Administrators Back up files and directories BUILTIN\Backup Operators, BUILTIN\Administrators Create a token object NT AUTHORITY\LOCAL SERVICE Deny log on through Terminal Services BUILTIN\Guests Replace a process level token NT AUTHORITY\NETWORK SERVICE, NT

AUTHORITY\LOCAL SERVICE Shut down the system BUILTIN\Backup Operators, BUILTIN\Administrators Local Policies/Security Options Accounts Policy Setting

Accounts: Administrator account status Enabled Accounts: Guest account status Disabled Accounts: Limit local account use of blank passwords to console logon only

Enabled

Accounts: Rename administrator account "admorganizationname" Audit Policy Setting

Audit: Shut down system immediately if unable to log security audits

Disabled

Interactive Logon Policy Setting

Interactive logon: Do not require CTRL+ALT+DEL Disabled Interactive logon: Message text for users attempting to log on

The information on this computer and network is the property, of this organization and is protected by intellectual property rights., You must be assigned an account on this computer to access information, and are only allowed to access information defined by the system, administrators. Your activities will be


Aldo Elam Majiah

monitored. Interactive logon: Message title for users attempting to log on

"Authorized Use Only!"

Interactive logon: Number of previous logons to cache (in case domain controller is not available)

2 logons

Microsoft Network Client Policy Setting

Microsoft network client: Digitally sign communications (always)

Enabled

Microsoft network client: Digitally sign communications (if server agrees)

Enabled

Microsoft Network Server Policy Setting

Microsoft network server: Digitally sign communications (always)

Enabled

Microsoft network server: Digitally sign communications (if client agrees)

Enabled

Network Access Policy Setting

Network access: Allow anonymous SID/Name translation

Disabled

Network access: Do not allow anonymous enumeration of SAM accounts

Enabled

Network access: Do not allow anonymous enumeration of SAM accounts and shares

Enabled

Network access: Let Everyone permissions apply to anonymous users

Disabled

Network Security Policy Setting

Network security: Do not store LAN Manager hash value on next password change

Enabled

Network security: LAN Manager authentication level Send NTLMv2 response only. Refuse LM & NTLM Network security: Minimum session security for NTLM SSP based (including secure RPC) clients

Enabled

Require NTLMv2 session security Enabled

Require 128-bit encryption Enabled

Network security: Minimum session security for NTLM SSP based (including secure RPC) servers

Enabled

Require NTLMv2 session security Enabled

Require 128-bit encryption Enabled

User Configuration (Enabled) No settings defined.


Aldo Elam Majiah

The last artifact is also the result of the risk assessment; it is a list of threat-countermeasure

pairs.


Aldo Elam Majiah


Aldo Elam Majiah

Appendix 8: Experts’ Opinion

Identification Opinion Expert 01 She suggested that one of AD components, security of network, might potentially

have a broader scope than the AD security itself since security of network could be interpreted as a very wide subject ranging from physical security of router/switch, port security, etc. She suggested renaming of the component into “security of network segmentation”. Additionally, she mentioned that threat caused by virtualization could be added to AD characterization step. Virtualization threats include inter-VM attack at the hypervisor level, multi-tenancy for AD, and lack of hardening at VM hosts.

Expert 02 He suggested the components of AD should have strong background theory and that AD Design & Boundary component is a critical component, which means that if this component fails, all other components will likely fail also. It is also suggested that the thesis also discusses ISO 31000 risk frameworks series to strengthen AD risk framework which is derived from NIST 800-30. Additionally, expert 02 also commented that GPO policy implementation may not be sufficient to secure a server / workstation; administrators may need to run Security Configuration Wizard to really secure a host.

Expert 03 He raised the concern of pass-the-hash attack on Windows platforms. He suggested that this attack should be added to the list of threats, as it could be used against DC and AD computer members. Pass-the-hash attack is a technique that allows an adversary to authenticate to a remote server/service by using the underlying NTLM and/or LanMan password hash instead of plaintext password. He also suggested that to prevent pass-the-has attack, administrators can define high privilege domain accounts, such as domain admins, to be able to login from certain hosts only. Although this countermeasure does not completely thwart the threat, it can limit pass-the-hash attack on domain accounts, thus preventing further escalation of privilege to the domain. This feature is available using ADUC. Another attack on Windows platform that can be added to the list of threat events is WPAD configuration poisoning, a threat that comes from Internet Explorer configuration flaw. Basically, an adversary could create a host, WINS entry, or DNS entry called WPAD and redirect traffic from IE to this host. WPAD threat can potentially enables adversary to take control of others’ proxy settings and retrieve users’ credentials for that proxy. To prevent this threat, administrators could create a DNS entry for “WPAD” tha points to corporate proxy server or they can also disable AutoDetect proxy settings on IE clients altogether using GPO. A comment was also added as a countermeasure for MITM attack on the network, by implementing static ARP configuration in the switch. A static ARP entry is a permanent entry in the ARP cache, it can be managed from a Cisco device or a Windows hosts. Implementation of IDS was also commented as not effective as IDS can only detect and log the attack, but take no action on the real time attack. It is preferably to replace IDS implementation with IPS. Screensaver implementation on unattended workstations is also deemed a necessary security countermeasure to prevent should surfing attack or disable the


Aldo Elam Majiah

Identification Opinion ability of an adversary to access unattended workstations. There was also a concern of data theft attack from Expert 03. Countermeasure of data theft, defined as disabling the use portable media, is not considered sufficient. Adversary can use other ways to steal and send the data outside the organization’s premises. Adversary could use email, ftp, or simply uploading the data to their servers. In order to truly prevent data theft, an organization can use a DLP solution. DLP solution is an integrated system designed to detect potential data breach or data ex-filtration. DLP prevent data theft by monitoring, detecting, and blocking sensitive data while the data are in-use in workstations, in-motion in network traffic, and at-rest at data storage. Last comment from Expert 03 was about environmental threat. Environmental threats should be placed outside “Security of AD computer members” component as both of these threats are different in nature, thus creating a new AD component called “Environmental threat”.

Expert 04 Expert 04 suggested that environmental threats should not be included in AD components. Environmental threat may be a threat for the organization, but it does not really relate to AD implementation in an organization. The security GPO resulted from the assessment may also be too restrictive for this organization. He mentioned that the GPO may not be suitable to be implemented in all environments, but it could be implemented in a more sensitive environment and highest security environment such as those handling more sensitive data, those subject to stricter compliance rules, top-secret government or military, and organizations which handling sensitive data.

Expert 05 Expert 05 recommended to rate the countermeasures in accordance to their threat’s risk level and also grouped them into people, process, and technology. As shown in the threat-countermeasure pairs, may be proper AD documentation is a countermeasure for a medium threat but privilege control is a countermeasure for high risk threat. Also, he stated, a vulnerability assessment can be grouped into “process” while lack of education can be grouped into “people”. He also stated that there should be two separated threats related to anti-virus, one is “incorrect configuration of anti-virus”, which is already in the list, and the other is “anti-virus not update”. The latter threat may still exist even though the anti-virus is correctly configured. For threat “insufficient log monitoring”, the countermeasure should include enablement of DNS logging. DNS logging is important because it can ease investigation in detecting from which computers attacker launches an attack by reviewing DNS requests. For example if there is a device that tries, say 500, different DNS requests and only one or two are valid then this device is most likely used in an attack. “Minimizing surface attack” is not really a threat but a countermeasure instead. It is a countermeasure for “lack of basic security hardening implementation” threat. And for this threat there should also be a countermeasure called “lack of security hardening standards”, which recommend us to have a proper documentation on hardening OS or application.


Aldo Elam Majiah

Identification Opinion “Mishandling of information” threat needs more control such as encryption of sensitive information. Three of the threats related to passwords; “rarely changed passwords”, “inadequate password policy implementation”, and “inadequate account lockout policy implementation” should be combined into one threat called “weak password”. A countermeasure for “weak password” threat includes all countermeasures for the three original threats and one additional countermeasure: “implementation of dual custody”.

Expert 06 He began with noting that there should be more information on how to implement the countermeasures. More specific guidelines are needed for implementing each of the countermeasures. He noted that for patch management, two solutions are needed; one is the monitoring (process side) and the other one is from the administrators that monitor it (people side). For MITM-based attack, he also added that static ARP implementation is not enough, there should be another countermeasure implemented in the switch that for “DHCP snooping” which allows only clients with specific IP/MAC addresses to have access to the network. In relation to sniffing threat, two countermeasures should be added. The first is to upgrade to a more secure protocol and the second is to perform a hardening on the switches’ physical access. Next comment is about installation of unauthorized applications. From network point of view, the organization can disable the use of unauthorized applications by performing whitelisting in the network’s firewall. As additional note, this would require a firewall that has the capabilities of identifying applications by their network signature. RAT (remote administration tools) and threat caused by these tools are considered important and deserve to be listed as a new item. These tools can use the existing infrastructure to make connection to outside the organization’s network. The countermeasures for this threat are anti-virus implementation and application-based firewall.


Aldo Elam Majiah

CURRICULLUM VITAE

Name : Aldo Elam Majiah

Place / Date of birth : Sukabumi / November 18th

, 1976

Mobile / Email : +6281319265243 / [email protected]

Description

Aldo is an IT technologist interested in IT security and infrastructure. He works as an IT

security consultant, performing various penetration testing projects mainly on Banking and

Telco’s IT infrastructure and web applications. His job also consists of hardening on Active

Directory and Windows servers. Previously he worked as administrator for Active Directory,

Windows servers / workstations, and Citrix systems.

Formal education :

ST, Bachelor of Engineering – Physics engineering ITB

SS, Bachelor of Art – English language UNPAD

IT certifications :

ECSA: EC-Council Certified Security Analyst v4

CEH: Certified Ethical Hacker version 5.0

CISSP: Certified Information Systems Security Professional

MCITP: Enterprise Administrator on Windows Server 2008

MCSE: Microsoft Certified System Engineer: Windows Server 2003

MCSA: Microsoft Certified System Administrator: Windows Server 2003

Microsoft Certified Solutions Associate: Windows Server 2008

CCA: Citrix Certified Administrator XenApp 5.0 on 2008

MCTS: Windows Server Virtualization (Hyper-V)

MCTS: System Center Configuration Manager (SCCM) 2007

MCTS: Windows Server 2008 Active Directory

MCTS: Windows Server 2008 Applications Infrastructure

MCTS: Windows Server 2008 Network Infrastructure

MCITP: Consumer Support Technician

MCTS: Windows Vista

Working experience: May 2012 – Now, company name: ITSEC Asia, position: Principal Consultant.

Sept 2011 – Apr 2012, company: PT Paserda Indonesia, position: IT Specialist – Server.

Aug 2010 – Sept 2011, company: PT Carrefour Indonesia, position: SysAdmin Manager

July2005 – Aug 2010, company: PT Mitra Integrasi Informatika, last position: Solution

Architect / Pre-sales consultant

mailto:[email protected]

finding countermeasures for active directory threats using nist 800-30 frameworks

Documents