Notes

STIG Overview

A STIG is a carefully crafted document that includes not only DoD policies and security regulations, but also up-to-date best practices and configuration guidelines. These guidelines are used for securing a specific system or application in accordance with DoD requirements. The recommendations and best practices in a STIG are gathered from a large community of STIG users. You will find that STIGs exist for many widely used operating systems, infrastructure services, and support applications, as well as for topics such as remote or wireless computing and networkings. STIGs have not yet been created for specific mission applications. Each STIG includes detailed guidelines to help you configure your systems for security and compliance with government Information Assurance (IA) requirements. STIGs can help you avoid and detect intrusion, respond to and recover from security breaches if they occur, and implement security policies.

You are more likely to receive certification from the Defense Information Systems Agency, or DISA, if you have configured your systems in accordance with the recommendations in a STIG. If you are developing applications for the DoD, STIGs provide guidance to ensure that your applications will be in compliance with DoD requirements. You can save significant time and money by referring to the appropriate STIG at the beginning of the development process. Each STIG is accompanied by a checklist that you can use to configure your system manually or to assess your system for compliance with DoD security guidelines. Some STIGs are even accompanied by scripts that automatically report where you are in compliance, or non-compliance, with guidelines.

Where do STIGs Come From?
A wide variety of STIGs are available and new STIGs are being released each year. Anyone who uses a STIG is a member of the STIG community and is encouraged to provide input into development and maintenance of STIGs. The STIG community includes representatives from DISA; the National Security Agency, or NSA; the Office of the Secretary of Defense, or OSD; combatant commands; military services; the National Institute of Standards and Technology, or NIST; and other organizations. Each September, DISA's Field Security Operations, or FSO, decide which new STIGs should written and which existing STIGs should be updated. These decisions are based on market trends, technological changes, customer requirements, and DoD policy and guidance.

You can provide input into the decisions about which STIGs are created and updated each year. For example, if you are using a new operating system or support application and a STIG does not exist, you can request that DISA create one. Each new STIG is created by FSO and disseminated to the STIG community in a draft form. After a STIG is released, DISA releases checklists to help you implement the requirements and recommendations in the STIG. Those checklists are updated monthly to incorporate the latest vulnerability notices and security patches. New checklists come out the fourth Friday of each month. DISA notifies the STIG community whenever a checklist is released or updated.

HBSS Overview
HBSS is a host based security system, which means it is located on the individual workstation or the host. It’s also a commercial-off the shelf (COTS) product. This suite uses multiple different modules to monitor, detect, and counter against known cyber threats. The system is configured and managed locally to address known traffic exploits.

Why do we use HBSS
Through Cyber Tasking Order (CTO) 07-12, US Cyber Command (USCYBERCOM) mandates that HBSS be installed on every DoD system. HBSS allows us to centralize the administration of security tools. With this centralized administration we can control and monitor our different modules (VSE, HIPS, DLP, and any other module that is installed on the host.

HBSS Components
The major components of HBSS are the ePolicy Orchestrator Server, the McAfee Agent, the distributed repositories, and the registered servers. The ePO server is an application server that manages the suit of products. In the DISA builds the ePO contains the SQL database that stores logs, events, and policies. It is also contains the master repository which stores all products as well as software that is deployable to the clients. The McAfee Agent is installed on the clients and allows the ePO server to enforce polices on the client machine. Distributed repositories are servers contain software packages for remote clients. These repositories are known as SADRs and are similar to that of a WSUS. Registered servers are additional servers on your network that you register with your ePO server to provide additional data such as LDAP, SNMP, and other ePO servers.

How It Works
Through the ePO’s web interface, you will create the policies. These policies tell each product how they will behave. The policies are then stored on the local ePO server or a remote database server. The agent on the client machine will pull the latest policy from the ePO server at a set interval and will apply them to the local host. The agents will continue to enforce the last policy it pulled from the ePO as long as the agent is running even if it has lost contact with the ePO server. The agent will also collect any events that has occurred since the last communication with the ePO and send them up to the ePO while getting the most current policy.

McAfee Agent Overview
The first component or module that we are to discuss is the McAfee Agent. The agent by itself offers no protection. Its job is to provide a secure communication channel to the ePO and manages all of the other modules that will be installed on the client machine (VSE, HIPS, etc.). There is also a second type of agent known as a SuperAgent. A SuperAgent are agents that are designated to act as a source of content updates to other agents in the same network. An example of when you would use a SuperAgent would if you’re using a WAN and you have part of your network that is at a remote site. Instead all of the machine trying to pull new policies and anti-virus updates over the WAN link, you would designate one machine to be your SuperAgent, and that machine will pull all of the updates and then push it out to the machines at the remote site.

The McAfee Agent
The agent is the module that will install all of your point products and upgrade based on the client task. It will also listen to the ePO server for any new policies and product updates (i.e. VSE DAT files) and then pass the new info to the product. In addition to passing information from the ePO server to the products, it also gathers events (intrusions, scan results, etc.) from the products and pushes them to the ePO server for analysis.

Agent to Server Communication Interval (ASCI)
The communication between the agent and the ePO server is called the agent to server communication interval (ASCI). This communication interval determines how often the agent checks in with the ePO. By default, this communication interval is 60 minutes. Depending on the size of your network, you can decrease that interval or if you have a really large network, then you will need to increase that time to reduce the amount of traffic on your network. At each ASCI, the agent collects and sends information it gathers from each module that is installed on the client. The agent will send events that occurred since the last ASCI. As the agent is sending info to the ePO, the ePO is sending any new policies or tasks. The last thing the agent does before it terminates ASCI is to enforce any policy that is has on hand.

Agent to Server Communication (ASCI)
ASCI is encrypted using Secure Sockets Layer (SSL) or Transport Layer Security (TLS). All encryption is 128-bit strength and, except for Mac OS X, is FIPS 140-2 compliant. There are multiple ways to initiate the agent-server communication. The first is when the ASCI default time lapses, the second is when the agent initiates a communication upon startup. The third is when the ePO initiates an agent wake-up call. The final way is to manually initiate communication from the client.

Communication After Agent Installation
The first thing that happens after the agent is installed on the client is that it initiates a communication to the ePO. The call to the server is at a randomized interval within the ten minutes of startup. The agent will upload the machine and product properties and events. At the same time, it will download any products, policies, and tasks.

Forcing Agent Activity from the Server
The administrator can force a communication to the client from the ePO. When a wake-up is sent, the machine or group of machines will reply to the request. Now all machines won’t answer back at the same time, instead the client will generate a random time and then respond. The randomization will prevent the ePO from being inundated with communications from the clients and DDOSing itself.

Wake-up calls & wake-up tasks
A wake-up call is when the ePO forces the managed machine to initiate an ASCI outside of its normal interval. There are two ways to issue a wake-up. The first is directly from the server. The other way is on a schedule. The schedule would be used if the ASCI was disabled due to bandwidth restrictions. Some reasons for issuing a wake-up call is to force a new policy change or task to the network immediately instead of waiting until the machine checks in on its own. You may also have a client that is out of compliance and you want to test status for troubleshooting.

Using the System Tray Icon
On a managed client you will see the McAfee Agent down in the system tray. The agent is a red shield with a white "M" on it. If you right click on the shield you will get a list of options for the agent. The first option you will want to click on is the "About…". The "About" will display system and product information for the products installed on the system. Some of the information includes the Agent Version, DAT Date/Version, ePO Server name/IP, Products Version, and the Hostname.

Using the System Tray Options
The other option that you will use quite often is the "McAfee Agent Status Monitor…". The monitor will display all communications between the agent and the server. This how you will be able to tell if the client has received the latest task or policy. It is also how you will manually initiate an ASCI so that you can manually send events and check for new policies or tasks. This will be your first step in troubleshooting.

Forcing Activity from the Client: Command Line
Now there might be a time that you will need to force an activity from the command line or you are trying to write a script to force the activity. From the command line, you want to change directories to the McAfee Agent ("C:Program FilesMcAfeeAgent"). To get all of the switch information for the cmdagent, you will want to type in "cmdagent.exe /?". Once you do that, you will get a list of what each switch is and what that switch does.

Agent Installation Options – New Systems
When it comes to deploying agents to your client machines, there are many options on how to do this. From the system tree, you will click on the "New System" button. From there you will get a new screen that has all of your options. One option is "How to add systems:" Here you can push agents and add systems to the current group, or push agents and place systems in the system tree according to sorting criteria, or just create and download agent installation package. If you choose to push the agent, then you will need to input your admin credentials.

Creating an Agent Install Package (FramePkg.exe)
Another option is to create an install package. This is easy because you can burn the install package to a disc and give it to your admins to manually install the agent or use as part of a startup script. One of the options when creating the install package is to embed your admin credentials. Do NOT enter in your admin credentials. If you do add in your credentials, then they will be embedded into the install pack. Now this may be convenient, it is inherently risky. Once you download that package and give it someone to install on their system, you run the risk that they will lose that disc and having someone steal your credentials.

Removing the McAfee Agent: Options
Now there is going to come a time that you will need to uninstall the agent from a machine. To do this there are two options. The first is to do it from the ePO system tree. From the System Tree: Select the checkbox next to the system. Use the Actions menu, navigate to Directory Management>Delete. You will then get a prompt. Be sure to select the option "at prompt to Uninstall agent at next ASCI". The other option is to uninstall the agent from the client. To uninstall from the client, you will need to your command line (be sure to run as admin). Next change your directory to "C:Program Files (x86)McAfeeCommon Frameworkx86". You will want to run the Frminst.exe with the following switches /Remove=Agent /forceuninstall. Using the command line is the only way to uninstall the agent, using the windows built-in add/remove programs will not work because McAfee will try to protect itself and prevent it from being uninstalled.

ACAS OVERVIEW
ACAS consists of a suite of products to include Red Hat Enterprise Linux, Security Center, Nessus Scanner and the Nessus Network Monitor (formerly the Passive Vulnerability Scanner) which is provided by DISA to DoD Customers. Security Center is the central console for ACAS. Security Center offers the ability to automate and quickly scale an organization’s vulnerability and compliance scanning infrastructure, as well as provide capabilities to allow for management, alerting, and reporting against vulnerability and compliance requirements.

Nessus is a fully capable scanner covers a breadth of checks, including unique Common Vulnerabilities and Exposures (CVEs), and successfully operates across different environments. Nessus Network Monitor (NNM) monitors network traffic in real-time. It determines server and client side vulnerabilities and sends these to Security Center in real-time. It continuously looks for new hosts, new applications, and new vulnerabilities without requiring the need for active scanning.

Defining Repositories
Repositories are proprietary data files, residing on the security center, that store scan results. Every time a scan is initiated, the scan results are imported into one repository. Scan data is retained according to administrator-defined expiration settings. Repositories are defined by an IP address range or the MDM data type.

Creating Repositories
Repositories are created by an administrator and then made available to organizations as appropriate. A single repository has a 32 GB limit and each are not organization specific. The access to a repository is controlled by an ACAS administrator. Multiple organizations may have access to the same repositories. When it comes to creating repositories the administrator assigns scan zones and repositories to organizations as appropriate. Those assignments can be changes as mission or technical needs change. It is important to understand that there is no direct link between scan zones and repositories. Each are assigned, independently, to the organizations allowed to use them.

Repository Types
There are 3 types of repositories:
1. Local
2. Remote
3. Offline

Local repositories are active repositories of Security Center data collected via scanners attached to the local Security Center. Remote repositories contain IP address and vulnerability information obtained via network synchronization with a second (remote) Security Center. Offline repositories enable Security Center to obtain repository data via manual file export/import from a remote Security Center that is not network-accessible. This may be useful for uploading scans from a standalone network scanner. Uploading exported Repository data will overwrite the imported Repository data.

Defining Audit Files
Audit Files are text files that contain the specific configuration, file permission, and access control tests to be performed. They are an attachment to a scan policy used with credentials to audit a host’s configuration. Audit files come from sources such as, Tenable network security templates (SC 5), DISA STIG automated benchmarks (.zip), and SCAP compliant checklists from NIST (.xccdf). You need to ensure that you are using tier 4 SCAP content because the lower tiers are not guaranteed to work in ACAS or any other SCAP-compliant tool.

Using DISA STIG Automated Benchmark Files
Security Center can create audit files by ingesting DISA STIG automated benchmark files in the .xccdf format. DISA STIG benchmark files are available on the IASE portal. ACAS only scans for and reports on automated checks and when you ingest the STIG benchmark you need to upload the entire zip file.

Using SCAP Content
Your security center also creates audit files by ingesting NIST’s SCAP files. NIST maintains the common configuration enumeration system. The site is http://nvd.nist.gov/cce/cfm. The SCAP file must be in .xccdf format and the content should be categorized by NIST as tier 4 content.

Uploading Audit Files
When it comes to uploading audit files they can be uploaded by anyone with the right permissions. Administrators can upload audit files for security center-wide usage, while authorized organizational users can upload them for use by their user group. When you upload audit file content, security center will create a plugin for each of the audit checks in the audit file.

Compliance
DISA will generate the STIGs based on secure recommendations from software vendors. Then the STIG configuration settings are converted to SCAP content, imported into Security Center, and used by Nessus Scanners to audit asset configurations for compliance. The National Vulnerability Database, or (NVD), is where NIST maintains the Common Configuration Enumeration (CCE) system. http://nvd.nist.gov/cce.cfm

Introduction to PKI
A Public Key Infrastructure is a framework that consists of hardware, software, people, processes, and policies, that together helps identify and solve information security problems for you by establishing safe and reliable environment for electronic transactions in the internet. It uses public key encryption techniques to protect the confidentiality, integrity, authenticity and non-repudiation of data. PKI is a uniform way for different organizations to identify people through their digital certificates containing public keys.

Authenticity is to be sure you know with whom you are communicating. Confidentiality is all about keeping secrets secret. Integrity is to be sure nothing is modified behind your back. And finally, non-repudiation is having the evidence in the event of a dispute.

Importance of PKI
In today's military, gathering, moving, and manipulating information electronically is fundamental to almost everything we do. This electronic information exchange and networking facilitates our ability to carry out our missions and make our lives easier. It also poses many threats to the security of our information. Information sent through a network is not just available to the designated recipient. It is also available to anyone who is looking in while the information is en route. Sending and accessing information over networks makes us vulnerable to hostile exploitation, data theft, viruses, and other malicious code, which can compromise user names and passwords. These threats degrade the inherent "trust" we place in networked computers. PKI provides us each with an additional way to secure our networks and regain "trust" in the electronic exchange of data and access of information.

Despite countermeasures that are already in place-such as antivirus software, firewalls, and intrusion detection technologies-we all must take greater security measures to protect our networks and data. PKI allows us to take advantage of the speed and immediacy of the Internet while assuring that we will be alerted if sensitive information has been tampered with and preventing unauthorized disclosure. Information security is mission critical and is everyone's responsibility. PKI provides every user with a way to protect DoD information, thereby improving information security and enabling the success of our missions.

PKI Guidance Documents
All policies start at the broad base of our constitution and public law, which is developed by Congress and issued into Congressional acts. The Executive Branch issues policy that guides the entire Federal Government. Government agencies create guidelines, publications, and standards. Some of the guidance, such as the Federal Information Processing Standards, or FIPS, authored by the National Institute of Standards and Technology, or NIST, were formally considered best practices, but have been made mandatory for Federal agencies by the Federal Information Security Management Act of 2002, or FISMA. Under FISMA, the Secretary of Defense and Director of National Intelligence may make separate, but equally stringent, standards for information systems under their authority.

While the DoD issues department-wide guidance, the Army, Navy, Marine Corps, and Air Force, issue specific implementation guidance for their individual service branches. Other DoD components and associated organizations, such as the Defense Agencies and Coast Guard, may issue specific implementation guidance. Congress has enacted a series of laws providing guidance to ensure the security of the information resources that support Federal Government operations and assets. Signed into law in December 2002, FISMA provides overarching requirements for the protection of Federal information and information systems.

In August 2004, the Executive Branch of the Federal Government issued Homeland Security Presidential Directive - 12, or HSPD-12, HSPD-12 mandated a common identification standard for Federal employees and contractors to enhance security, increase Government efficiency, reduce identity fraud, and protect personal privacy. In the DoD, this common identification standard is currently implemented by the CAC. DoD has issued several PKI guidance documents. There are three DoD policy documents that mandate the use of PKI; DoDD 8500.01E, DoDI 8520.2, DoDD 8190.3. In addition, there are two communication tasking orders, or CTOs, that implement these policies; JTF-GNO CTO 07-15, JTF-GNO CTO 06-02.

PKI Components
PKI consists of five components that work together to ensure information security. These components are systems, software, tokens, certificates, and keys. Systems must be public key enabled to interface with PKI. This involves replacing existing authentication systems or creating new user authentication systems using PKI certificates, instead of previous technologies, such as user ID and password. Certicate Authorities (CA) issue and authenticate certificates and keys. For example, the computers you use to log into the training network have controlled access through PKI and Cryptographic Logon (CLO), which require you to use your PKI certificates on your CAC and your CAC PIN to authenticate your identity to access these computers.

Software, too, must be public key enabled to realize the securities that PKI provides. For example, Microsoft Outlook is public key enabled so that you may digitally sign and encrypt e-mail and attached documents. Beginning in 2002, the Smart Card Logon purpose was added to the email signing certificate. This is the certificate used for CLO. The SubjectAltName field in the email signature certificate details includes the EDIPI@mil. Electronic Data Interchange - Person Identifier (EDI-PI) is the 10 digit number associated with your CAC. This field is compared in Active Directory (AD) when you log on using the CAC. To set up CLO, you must create and install a certificate to authenticate the domain controller to the clients. Next you must set up Active Directory to include each user’s 10-digit EDI-PI in the logon name field.

Symmetric-key vs Asymmetric-key
There are two different types of cryptographic methods used to decrypt and encrypt data. Symmetric method works exactly the same way your door lock works. You have one key to lock or open the door. This is also called as shared secret and private key. Asymmetric-key method on the other hand uses a key pair to do the encryption and decryption. It includes two keys one is public key and the other one is private key. The public key is always distributed to the public and anyone can have it whereas the private key is unique for the object and it will not be distributed to others. Any message that is encrypted using a public key can only be decrypted using a private key. Vise versa, any message that is encrypted using a private key can only be decrypted using a public key. PKI uses the Asymmetric-key method for digital encryption and digital signature.

Active Directory Certificate Service Components
Active Directory Certificate Service is the Microsoft solution for PKI. It is collection of role services to use to design the PKI for your organization. We are going to look in to each of these role service and their responsibilities. Certificate Authority (CA) is the role service holders responsible for issue, store, manage and revoke certificates. PKI setup can have multiple CAs. There are mainly two types of CA which can identify in PKI; Root CA and Subordinate CA. Root CA is the most trusted CA in PKI environment. Compromise of root CA will possibly compromise the entire PKI. Because of the security of the root CA is critical, most organization only bring those online when they need to issue or renew a certificate. The root CA is also capable of issuing certificates to any object or services but considering security and hierarchy of the PKI it is used to issue certificates only to Subordinate CAs. In PKI, Subordinate CAs are responsible for issues, store, manage and revocation of certificates for objects or services.

These publish certificate templates and users can create their certificate requests based on those templates. Once CA receives the request it will process it and issue the certificate. PKI can have multiple subordinate CAs. Each subordinate server should have its own certificate from the root CA. the validity period of these certificates is normally longer than ordinary certificates. It also needs to renew its certificate from root CA when it reaches the end of validity period. Subordinate CA can have more subordinate CAs below it. in such situation, Subordinate CA also responsible for issuing certificates for its more subordinate CAs. These Subordinate CAs which have more Subordinate CAs called as Intermediate CA. These will not be responsible for issues certificates to users, devices or services. Then it will become more subordinate CA’s responsibilities. The more subordinate servers which issues certificates will call as Issuing CA.



PKI Two Tier Model
This is the most commonly used PKI deployment model in corporate networks. The root CA will be kept offline and it will prevent the private key of the root CA from being compromised. The root CA will issue certificates for subordinate CAs and Subordinate CAs are responsible for issuing certificates for objects and services. When the Subordinate CAs certificate expires, the offline root CA will need to be brought online to renew the certificate. The root CA doesn’t need to be a domain member and it should be operating in workgroup level (standalone CA). There for the certificate enrollment, approval and renew will be manual process. This is scalable solution and number of issuing CAs can be increase based on workloads. This allows to extend the CA boundaries to multiple sites too. In Single-Tier model if PKI got compromised all of the issuing certificates need to be manually removed from the devices. In Two-Tier model, all you need to do is revoke the certificates issued by CA and then publish CRL (Certificate Revocation List) and then reissue the certificates.