430-W3-Benchmark—Applying-Advanced-Protocols.docx

IPSec : Internet Protocol Security or IP Security

IPsec, also known as the Internet Protocol Security or IP Security protocol, defines the architecture for security services for IP network traffic.

IPsec describes the framework for providing security at the IP layer, as well as the suite of protocols designed to provide that security, through authentication and encryption of IP network packets.

Also included in IPsec are protocols that define the cryptographic algorithms used to encrypt, decrypt and authenticate packets, as well as the protocols needed for secure key exchange and key management.

IPsec originally defined two mechanisms for imposing security on IP packets: the Encapsulating Security Payload (ESP) protocol, which defined a method for encrypting data in IP packets, and the Authentication Header (AH) protocol, which defined a method for digitally signing IP packets. The Internet Key Exchange (IKE) protocol is used to manage the cryptographic keys used by hosts for IPsec.

propose to implement IPSec

· We propose to implement IPSec to secure data transport. IPSec is a protocol suite for networking devices

to communicate privately using IP.

· Infrastructure that will allow resources to authenticate other resources directly, without appealing to a central

authority like Kerberos. We propose to use the security extensions to the DNS protocol, referred to as the DNSSEC extensions.

· DNSSec and secure key management

The fundamental objectives of DNSSEC are to provide authentication and integrity to the inherently insecure

DNS.· Authentication and integrity of information held within DNS zones are provided through cryptographic

signatures generated through the use of public key technology. Security aware servers and applications can

assure that the information obtained from a secured DNS server has not been altered and authenticated.

· To make our secure network transport scalable, we propose to modify the SSH client to query the DNS server

for the host key of an SSH server.

Q2.

The domain name system resolves domain names to IP addresses. DNS security extensions can validate the integrity of the chain of trust, ensuring that users are visiting the correct website.

Domain name system security extensions (DNSSEC) is a protocol for securing the chain of trust that exists between the domain name system (DNS) records that are stored at each domain level, verifying each trust between the child level and its parent, all the way back to the root zone. Through this multi-level process, the integrity of the DNS records associated with a domain can be verified, thus ensuring to the client that the website or service requested and the one delivered are in fact, one and the same.

This article gives a brief explanation of how DNSSEC works and why your company should consider implementing it.

How does DNSSEC function?

To demonstrate, let’s consider that our website is hosted as test.themacjesus.com.

The first step in the process requires the “.com” name servers to verify the records for “themacjesus” (in a parent-child relationship). Second, “themacjesus” verify the records for “test” (also in a parent-child relationship). Third, the root DNS servers verify the .com records. Lastly, the records published by the root have their integrity verified using a private-public key pair, called a Zone Signing Key (ZSK). Additionally, a secondary key pair called the Key Signing Key (KSK) is used to validate the ZSK.

Just like DNS, DNSSEC is invisible to the user. However, in the background, the security extensions work by effectively signing the root zone for your domain, with each subsequent record requiring verification from its parent until the site being requested has been validated.

What does DNSSEC protect against?

Accessing validated websites and services is the aim of security extension-enabled DNS services. The goal here is to reach the intended servers hosting those sites or services. As far as protection goes, it ensures against malicious URLs designed to impersonate a site or service for the purpose of harvesting account names and passwords. This could come in the form of a maliciously injected record during a man-in-the-middle attack or as part of a known vulnerability, such as DNS-cache poisoning or spoofing attacks. In either case, DNSSEC will reply with a 404 error (website not found) in the event that a domain does not resolve due to DNS records that can’t be validated.

How do you enable DNSSEC?

Enabling DNSSEC for your organization’s DNS servers is generally a multi-step process that, while not complicated, will vary depending on your domain’s registrar, the top-level domain (TLD) extension for your site, and the nameservers’ configuration, whether managed internally or by a 3rd-party.

Some managed solutions, like CloudFlare, essentially allow DNSSEC to be enabled through several clicks of a mouse for users who utilize its fully managed DNS services. For self-managed nameservers, there is more to the configuration and setup that may require specific information to correctly implement DNSSEC. While a generalized setup is covered below in setting up DNSSEC, organizations should contact their IT support teams and any 3rd-party services they’ve contracted to manage domain services to understand exactly what the process will involve to successfully enable DNSSEC.

Setting up DNSSEC

1. Verify that your TLD supports DNS Security Extensions.

2. Speak to your IT department and 3rd-party domain service providers to obtain DNSSEC-specific requirements.

3. Generate the zone signing key (ZSK) and key signing key (KSK) for your domain’s DNS zone.

4. Sign your DNS zone to generate signed zone records for your domain(s).

5. Generate the Declaration of Signing (DS) record, which contains hashed values for the cryptographic keys used to sign your DNS zone.

6. Import the DS record(s) for your domain(s) to the self-hosted or fully managed nameserver, ensuring that the information obtained in step #2 is available, if needed.

7. (Optional) Use to check each link in the chain of trust to diagnose any issues affecting the implementation of DNSSEC on your domain(s).

3.Procedure: Deploy IPsec Policy to DNS Servers

Applies To: Windows Server 2012 R2, Windows Server 2012

Use the following procedure to configure IP Security (IPsec) rules for the DNS servers in your organization that will provide DNS resolution for client computers. IPsec rules are configured to request authentication for all DNS queries.

You can deploy IPsec rules through one of the following mechanisms:

· Domain Controllers organizational unit (OU): If the DNS servers in your domain are Active Directory-integrated, you can deploy IPsec policy settings using the Domain Controllers OU. This option is recommended to make configuration and deployment easier.

· DNS Server OU or security group: If you have DNS servers that are not domain controllers, then consider creating a separate OU or a security group with the computer accounts of your DNS servers.

· Local firewall configuration: Use this option if you have DNS servers that are not domain members or if you have a small number of DNS servers that you want to configure locally.

Interested in learning about Domain Name System Security Extensions (DNSSEC)? Click the image below to explore our infographic, which describes what DNSSEC is and outlines the benefits of deploying DNSSEC.

A brief description of how DNS works

To understand Domain Name System Security Extensions (DNSSEC), it helps to have a basic understanding of the Domain Name System (DNS).

The proper functioning of the Internet is critically dependent on the DNS . Every web page visited, every email sent, every picture retrieved from a social media: all those interactions use the DNS to translate human-friendly domain names (such as icann.org) to the IP addresses (such as 192.0.43.7 and 2001:500:88:200::7) needed by servers, routers, and other network devices to route traffic across the Internet to the proper destination.

Using the Internet on any device starts with the DNS. For example, consider when a user enters a web site name in a browser on their phone. The browser uses the stub resolver, which is part of the device’s operating system, to begin the process of translating the web site’s domain name into an Internet Protocol (IP) address. A stub resolver is a very simple DNS client that relays an application’s request for DNS data to a more complicated DNS client called a recursive resolver. Many network operators run recursive resolvers to handle DNS requests, or queries, sent by devices on their network. (Smaller operators and organizations sometimes use recursive resolvers on other networks, including recursive resolvers operated as a service for the public, such as Google Public DNS, OpenDNS, and Quad9.)

The recursive resolver tracks down, or resolves, the answer to the DNS query sent by the stub resolver. This resolution process requires the recursive resolver to send its own DNS queries, usually to multiple different authoritative name servers. The DNS data for every domain name is stored on an authoritative name server somewhere on the Internet. DNS data for a domain is called a zone. Some organizations operate their own name servers to publish their zones, but usually organizations outsource this function to third parties. There are different types of organizations that host DNS zones on behalf of others, including registrars, registries, web hosting companies, network server providers, just to name a few.

DNS by itself is not secure

DNS was designed in the 1980s when the Internet was much smaller, and security was not a primary consideration in its design. As a result, when a recursive resolver sends a query to an authoritative name server, the resolver has no way to verify the authenticity of the response. The resolver can only check that a response appears to come from the same IP address where the resolver sent the original query. But relying on the source IP address of a response is not a strong authentication mechanism, since the source IP address of a DNS response packet can be easily forged, or spoofed. As DNS was originally designed, a resolver cannot easily detect a forged response to one of its queries. An attacker can easily masquerade as the authoritative server that a resolver originally queried by spoofing a response that appears to come from that authoritative server. In other words an attacker can redirect a user to a potentially malicious site without the user realizing it.

Recursive resolvers cache the DNS data they receive from authoritative name servers to speed up the resolution process. If a stub resolver asks for DNS data that the recursive resolver has in its cache, the recursive resolver can answer immediately without the delay introduced by first querying one or more authoritative servers. This reliance on caching has a downside, however: if an attacker sends a forged DNS response that is accepted by a recursive resolver, the attacker has poisoned the cache of the recursive resolver. The resolver will then proceed to return the fraudulent DNS data to other devices that query for it.

As an example of the threat posed by a cache-poisoning attack, consider what happens when a user visits their bank’s website. The user’s device queries its configured recursive name server for the bank web site’s IP address. But an attacker could have poisoned the resolver with an IP address that points not to the legitimate site but to a web site created by the attacker. This fraudulent website impersonates the bank website and looks just the same. The unknowing user would enter their name and password, as usual. Unfortunately, the user has inadvertently provided its banking credentials to the attacker, who could then log in as that user at the legitimate bank web site to transfer funds or take other unauthorized actions.

The DNS Security Extensions (DNSSEC)

Engineers in the Internet Engineering Task Force (IETF), the organization responsible for the DNS protocol standards, long realized the lack of stronger authentication in DNS was a problem. Work on a solution began in the 1990s and the result was the DNSSEC Security Extensions (DNSSEC).

DNSSEC strengthens authentication in DNS using digital signatures based on public key cryptography. With DNSSEC, it’s not DNS queries and responses themselves that are cryptographically signed, but rather DNS data itself is signed by the owner of the data.

Every DNS zone has a public/private key pair. The zone owner uses the zone’s private key to sign DNS data in the zone and generate digital signatures over that data. As the name “private key” implies, this key material is kept secret by the zone owner. The zone’s public key, however, is published in the zone itself for anyone to retrieve. Any recursive resolver that looks up data in the zone also retrieves the zone’s public key, which it uses to validate the authenticity of the DNS data. The resolver confirms that the digital signature over the DNS data it retrieved is valid. If so, the DNS data is legitimate and is returned to the user. If the signature does not validate, the resolver assumes an attack, discards the data, and returns an error to the user.

DNSSEC adds two important features to the DNS protocol:

· Data origin authentication allows a resolver to cryptographically verify that the data it received actually came from the zone where it believes the data originated.

· Data integrity protection allows the resolver to know that the data hasn’t been modified in transit since it was originally signed by the zone owner with the zone’s private key.

Trusting DNSSEC keys

Every zone publishes its public key, which a recursive resolver retrieves to validate data in the zone. But how can a resolver ensure that a zone’s public key itself is authentic? A zone’s public key is signed, just like the other data in the zone. However, the public key is not signed by the zone’s private key, but by the parent zone’s private key. For example, the icann.org zone’s public key is signed by the org zone. Just as a DNS zone’s parent is responsible for publishing a child zone’s list of authoritative name servers, a zone’s parent is also responsible for vouching for the authenticity of its child zone’s public key. Every zone’s public key is signed by its parent zone, except for the root zone: it has no parent to sign its key.

The root zone’s public key is therefore an important starting point for validating DNS data. If a resolver trusts the root zone’s public key, it can trust the public keys of top-level zones signed by the root’s private key, such as the public key for the org zone. And because the resolver can trust the public key for the org zone, it can trust public keys that have been signed by their respective private key, such as the public key for icann.org. (In actual practice, the parent zone doesn’t sign the child zone’s key directly–the actual mechanism is more complicated–but the effect is the same as if the parent had signed the child’s key.)

The sequence of cryptographic keys signing other cryptographic keys is called a chain of trust. The public key at the beginning of a chain of trust is a called a trust anchor. A resolver has a list of trust anchors, which are public keys for different zones that the resolver trusts implicitly. Most resolvers are configured with just one trust anchor: the public key for the root zone. By trusting this key at the top of the DNS hierarchy, a resolve can build a chain of trust to any location in the DNS name space, as long as every zone in the path is signed.

Validating and Signing with DNSSEC

In order for the Internet to have widespread security, DNSSEC needs to be widely deployed. DNSSEC is not automatic: right now it needs to be specifically enabled by network operators at their recursive resolvers and also by domain name owners at their zone’s authoritative servers. The operators of resolvers and of authoritative servers have different incentives to turn on DNSSEC for their systems, but when they do, more users are assured of getting authenticated answers to their DNS queries. Quite simply, a user can have assurance that they are going to end up at their desired online destination.

Enabling DNSSEC validation in recursive resolvers is easy. In fact, it has been supported by nearly all common resolvers for many years. Turning it on involves changing just a few lines in the resolver’s configuration file. From that point forward, when a user asks the resolver for DNS information that comes from zones that are signed, and that data has been tampered with, the user will (purposely) get no data back. DNSSEC protects the user from getting bad data from a signed zone by detecting the attack and preventing the user from receiving the tampered data.

Signing zones with DNSSEC takes a few steps, but there are millions of zones that sign their DNS information so that users of validating resolvers can be assured of getting good data. Almost all common authoritative name server software supports signing zones, and many third-party DNS hosting providers also support DNSSEC. Usually, enabling DNSSEC for a zone with a hosting provider is quite easy: often it entails little more than clicking a check box.

For a zone owner to deploy DNSSEC by signing their zone’s data, that zone’s parent, and its parent, all the way to the root zone, also need to be signed for DNSSEC to be as effective as possible. A continuous chain of signed zones starting at the root zone allows a resolver to build a chain of trust from the root zone to validate data. For example, to effectively deploy DNSSEC in the icann.org zone, the org zone needs to be signed as well as the root zone. Fortunately, the DNS root zone has been signed since 2010, and all gTLDs and many ccTLDs are also signed.

There is one more step to complete DNSSEC deployment in a zone: the newly signed zone’s public key material needs to be sent to the zone’s parent. As described earlier, the parent zone signs the child zone’s public key, and allows a chain of trust to be built from parent to child.

Today the zone owner usually needs to communicate the zone’s public key material to the parent manually. In most cases, that communication happens through the zone owner’s registrar. Just as a zone owner interacts with its registrar to make other changes to a zone, such as the list of the zone’s authoritative name servers, the zone owner also interacts with the registrar to update the zone’s public key material. While this process is currently manual, recently developed protocols are expected to allow this process to be automated in the future.

The next steps for DNSSEC

As DNSSEC deployment grows, the DNS can become a foundation for other protocols that require a way to store data securely. New protocols have been developed that rely on DNSSEC and thus only work in zones that are signed. For example, DNS-based Authentication of Named Entities (DANE) allows the publication of Transport Layer Security (TLS) keys in zones for applications such as mail transport. DANE provides a way to verify the authenticity of public keys that does not rely on certificate authorities. New ways of adding privacy to DNS queries will be able to use DANE in the future, as well.

In 2018, ICANN changed the trust anchor for the DNS root for the first time. Many lessons were learned about DNSSEC during that process. Furthermore, many resolver operators became more aware of DNSSEC and turned on validation, and the world got to more clearly see how the entire DNSSEC system worked. In the coming years, ICANN hopes to see greater adoption of DNSSEC, both by resolver operators and zone owners. This would mean that more users everywhere could benefit from DNSSEC’s strong cryptographic assurance that they are getting authentic DNS answers to their queries.

3.1. Cryptography tools/algorithm or protocalls

· Internet Protocol Security (IPSec). IPSec provides encryption and/or authentication at the IP packet level. However, IPSec is often used in a way that only guarantees authenticity of two communicating hosts, not of the users. As a practical matter, IPSec usually requires low-level support from the operating system (which not all implement) and an additional keyring server that must be configured. Since IPSec can be used as a “tunnel” to secure packets belonging to multiple users and multiple hosts, it is especially useful for building a Virtual Private Network (VPN) and connecting a remote machine. As of this time, it is much less often used to secure communication from individual clients to servers. The new version of the Internet Protocol, IPv6, comes with IPSec “built in,” but IPSec also works with the more common IPv4 protocol. Note that if you use IPSec, don’t use the encryption mode without the authentication, because the authentication also acts as integrity protection.

· Secure Socket Layer (SSL) / TLS. SSL/TLS works over TCP and tunnels other protocols using TCP, adding encryption, authentication of the server, and optional authentication of the client (but authenticating clients using SSL/TLS requires that clients have configured X.509 client certificates, something rarely done). SSL version 3 is widely used; TLS is a later adjustment to SSL that strengthens its security and improves its flexibility. Currently there is a slow transition going on from SSLv3 to TLS, aided because implementations can easily try to use TLS and then back off to SSLv3 without user intervention. Unfortunately, a few bad SSLv3 implementations cause problems with the backoff, so you may need a preferences setting to allow users to skip using TLS if necessary. Don’t use SSL version 2, it has some serious security weaknesses.

Symmetric Key Encryption Algorithms

1)

Public Key Algorithms

For public key cryptography (used, among other things, for signing and sending secret keys), there are only a few widely-deployed algorithms. One of the most widely-used algorithms is RSA; RSA’s algorithm was patented, but only in the U.S., and that patent expired in September 2000, so RSA can be freely used. Never decrypt or sign a raw value that an attacker gives you directly using RSA and expose the result, because that could expose the private key (this isn’t a problem in practice, because most protocols involve signing a hash computed by the user – not the raw value – or don’t expose the result). Never decrypt or sign the exact same raw value multiple times (the original can be exposed). Both of these can be solved by always adding random padding (PGP does this) – the usual approach is called Optimal Asymmetric Encryption Padding (OAEP).

2)Cryptographic Hash Algorithms

Some programs need a one-way cryptographic hash algorithm, that is, a function that takes an “arbitrary” amount of data and generates a fixed-length number that hard for an attacker to invert .

Don’t use the original SHA (now called “SHA-0”); SHA-0 had the same weakness that MD5 does. After MD5 was broken, SHA-1 was the typical favorite, and it worked well for years.

However, SHA-1 has also become too weak today; SHA-1 should never be used in new programs for security, and existing programs should be implementing alternative hash algorithms. Today’s programs should be using better and more secure hash algorithms such as SHA-256 / SHA-384 / SHA-512 or the newer SHA-3.

3) Integrity Checking

When communicating, you need some sort of integrity check (don’t depend just on encryption, since an attacker can then induce changes of information to “random” values). This can be done with hash algorithms, but don’t just use a hash function directly (this exposes users to an “extension” attack – the attacker can use the hash value, add data of their choosing, and compute the new hash). The usual approach is “HMAC”, which computes the integrity check as

H(k xor opad, H(k xor ipad, data)).

where H is the hash function and k is the key. .

3.2

purpose of IPsec

The IP security (IPSec) is an Internet Engineering Task Force (IETF) standard suite of protocols between 2 communication points across the IP network that provide data authentication, integrity, and confidentiality. It also defines the encrypted, decrypted and authenticated packets. The protocols needed for secure key exchange and key management are defined in it.

Uses of IP Security –

IPsec can be used to do the following things:

· To encrypt application layer data.

· To provide security for routers sending routing data across the public internet.

· To provide authentication without encryption, like to authenticate that the data originates from a known sender.

· To protect network data by setting up circuits using IPsec tunneling in which all data is being sent between the two endpoints is encrypted, as with a Virtual Private Network(VPN) connection.

Components of IP Security –

It has the following components:

1. Encapsulating Security Payload (ESP) –

It provides data integrity, encryption, authentication and anti replay. It also provides authentication for payload.

2. Authentication Header (AH) –

It also provides data integrity, authentication and anti replay and it does not provide encryption. The anti replay protection, protects against unauthorized transmission of packets. It does not protect data’s confidentiality.

3. Internet Key Exchange (IKE) –

It is a network security protocol designed to dynamically exchange encryption keys and find a way over Security Association (SA) between 2 devices. The Security Association (SA) establishes shared security attributes between 2 network entities to support secure communication. The Key Management Protocol (ISAKMP) and Internet Security Association which provides a framework for authentication and key exchange. ISAKMP tells how the set up of the Security Associations (SAs) and how direct connections between two hosts that are using IPsec.

4. Internet Key Exchange (IKE) provides message content protection and also an open frame for implementing standard algorithms such as SHA and MD5. The algorithm’s IP sec users produces a unique identifier for each packet. This identifier then allows a device to determine whether a packet has been correct or not. Packets which are not authorized are discarded and not given to receiver.

3.4 . CHALLENGES AND SECURITY TRADE-OFFS

· .The enterprise security architecture starts from the enterprise security policy regarding security risks based on the enterprise context. The enterprise security policy sets the direction for the security manager to identify the enterprise security requirements, security services and security standards, which takes the general goals and restates them in terms of specific technology areas.

· Authentication and Access Control: In an enterprise network, authentication is the process of reliably verifying the identity of a person, or verifying the origin of data as authentic, or assuring that a computer program is a trusted one. Authorization is the process of granting or denying access of a person, a process, or a machine to a network resource (Anderson 2008). Authentication and authorization are a two-step access control process.

· Confidentiality: Confidentiality has been defined by the International Organization for Standardization (ISO) as “ensuring that information is accessible only to those authorized to have access (ISO 2004).” Confidentiality is one of the cornerstones of information security.

· Communication Integrity: The goal of communication integrity is to maintain data consistency. More specifically, communication integrity service assures that the messages are received as sent, with no duplication, insertion, modification, reordering, or replays. Enterprises are more concerned with accuracy and data integrity against unauthorized modification than disclosure in certain cases as unauthorized modification can be caused by virus and malicious software.

· Non-Repudiation: Non-repudiation is a security service used to prevent either the sender or the receiver from denying a transmitted message. Thus, when a message is sent, the receiver can prove that the alleged sender in fact sent the message. Similarly, when a message is received, the sender can prove that the alleged receiver in fact received the message. Non-repudiation is also sometimes called third party authentication.

· Availability: The goal of availability is to ensure that information, systems, data, networks, and applications can be used or reachable at any time needed by an authorized system entity. A variety of attacks can result in the loss of or reduction in availability

Take a moment to review the details of this assignment below and gather any necessary files. Once you’re ready to submit your assignment, move on to Step 2.

Assessment Description

This assignment will provide an exercise in the implementation of IPsec and DNSSEC that are used in today’s corporate infrastructures.

1. Using the virtual environment created and modified in Topics 1 and 2. On your primary domain controller (e.g., ITT430-Across The States Bank), conduct the following procedures outlined in the “ITT-430: IPSec & DNSSEC Implementation Instructions.” (Attached)

2. Enable IPsec and DNSSEC to enhance the protection of the domain. Note: IPsec is a security protocol that provides network-based authentication and confidentially between servers via a set of standards, while DNSSEC is a set of extensions that provide integrity to the DNS server to aid in the deterring attackers from hijacking the DNS process.

3. After completing the above procedures, attach the appropriate screenshots into a single MS Word document and complete the following tasks.

Using the above enterprise architecture scenario, which consists of different components (e.g., servers, clients, databases) with information that has various temporal and distribution constraints, networks, multiple sites, and trusted and untrusted clients, write a 500- to 750-word summary, making sure to:

1. Describe the appropriate cryptographic tools/algorithms/protocols that can be applied at various locations throughout that architecture in order to achieve a variety of goals.

2. Define the purpose of IPsec (including the various modes, IKE, ESP vs AH, Windows firewall integration, and IPv6) and DNSSEC (relationship to PKI, DNS Zones, and trust anchors).

3. Briefly describe what you accomplished from the procedures supplied, and how these protocols enhance the security of servers. Provide references to recent articles (less than a year old) that demonstrate the use and benefits of an organization that has implemented IPsec and DNSSEC.

4. Describe the management challenges/tradeoffs associated with implementing various security controls and protocols in an enterprise network.

5. Include the required screenshots as outlined in the implementation instructions.

Take a moment to review the details of this assignment below and gather any necessary files. Once you’re ready to submit your assignment, move on to Step 2.

Assessment Description

During this assignment, students will create the virtual environment that will be used to implement security controls and policies. The processes in this assignment will establish a baseline to which secure hardening practices will be applied in future topics.

Use the GCU Virtualization Solutions to create three virtual systems that meet the following criteria:

Use this naming scheme, applying the same association established in the assignment “Developing Enterprise Framework for a Security Program”: ITT430-ASB#:

Examples: ‘Across the States Bank (ASB)’: ITT430-ASB1, Example ‘Across the States Bank (ASB)’: ITT430-ASB2, Domain ‘Across the States Bank (ASB)’: CORP.ITT430ASB.COM

A Windows Server (Latest Version) (English) Domain Controller with the following services installed (at minimum):

1. Server Role: Active Directory Domain Services (ADDS) – Promote to DC

2. Server Role: DNS Server

3. Features: Group Policy Management

A Windows Server (Latest Version) (English) with the following services installed (at minimum):

1. Add as member server to domain

2. Server Role: Application Server

3. Server Role: Web Server

4. Features: .Net Framework

5. Role Services: Web Server (IIS) Support

A Windows Server (Latest Version) (English) with the following services installed (at minimum):
1. Add as member server to domain

2. Default installation

NOTE: Do not install antivirus software or install system updates at this time.

Capture two screenshots of the Active Directory User and Computers tree that includes the three servers above, paste them into a ‘ x’ file, and submit it to the digital classroom.

1. Screenshot #1: Active Directory Users and Computers – Open Domain folder, click on Computers folder to display two computers added to the domain.

2. Screenshot #2: Active Directory Users and Computers – Open Domain folder, click on Domain Controllers folder to display single domain controller of domain.

APA style is not required, but solid academic writing is expected.

THIS IS DONE ALREADY AS SEEN BELOW

Take a moment to review the details of this assignment below and gather any necessary files. Once you’re ready to submit your assignment, move on to Step 2.

Assessment Description

During this assignment, students will conduct a vulnerability assessment based on various security frameworks using an industry standard vulnerability scanner. The scan will be conducted on all three Windows Servers within your virtual environment created in the Topic 1 assignment.

Part 1

1. Download and install Nessus Essentials (free) vulnerability scanner on your Windows Standard Server.

2. Conduct a vulnerability scan on all three servers.

3. In a 250- to 500-word technical report, summarize the findings, to include the number of critical vulnerabilities discovered. Make sure to include screen shots of the completed scans.

Part 2

1. Perform a Windows update on all three servers. Make sure that you have completely updated each server with all applicable patches, service packs, and security updates.

2. Conduct a second vulnerability scan on all three servers.

3. Compare the results of your first scan with the second scan after updates. What was the percentage of improvements?

4. In the same report, present a 250- to 500-word summary of the findings, including the percentage of reduced vulnerabilities. Make sure to include screenshots of the completed scans.