Posts

Top Ten—Things You Should Know about eMASS

Top Ten—Things You Should Know about eMASS

By Lon J. Berman, CISSP

The Enterprise Mission Assurance Support Service, or eMASS, is a web-based Government off-the-shelf (GOTS) solution that automates a broad range of services for comprehensive, fully-integrated cybersecurity management, including controls scorecard measurement, dashboard reporting, and the generation of Risk Management Framework (RMF) package reports.

The Enterprise Mission Assurance Support Service, or eMASS, is a web-based Government off-the-shelf (GOTS) solution that automates a broad range of services for comprehensive, fully-integrated cybersecurity management, including controls scorecard measurement, dashboard reporting, and the generation of Risk Management Framework (RMF) package reports.

If you’re not yet using eMASS to support your RMF activities, here are 10 things you probably need to know. If you’re already using eMASS, please read on; you’ll probably learn a few new things!

10. eMASS is not a single, integrated system. There are actually separate eMASS “instances” (i.e., databases) for each DoD component (e.g., Army, Navy, Air Force, DISA, NGB, DHRA, DAU, etc.). There is limited ability for one database to “reach across” to another (e.g., to implement control inheritance).

9. A few DoD components are not currently using eMASS because they have “standardized” on a different tool for RMF support. Even within DoD components that are “standardized” on eMASS, there may be individual commands or programs that are not participating.

8. Each DoD component has its own process for access approval. In most cases, a DD 2875 form is required, along with evidence of completion of DISA eMASS training (see below).

7. DISA provides a short online eMASS training course that is required in order to obtain an account, as well as limited classroom training. Commercial training providers offer various in-depth online and classroom training programs.

6. Access to eMASS requires a DoD Common Access Card (CAC) - no exceptions!

5. Most eMASS databases are accessible from NIPRNET only (not internet). This can be problematic for contractors who typically work off-site. In those cases, the DoD customer needs to provide some sort of “remote access” solution (e.g., VPN, Citrix, VDI) that enables off-site contractors to get “virtual” NIPRNET access. A few of the eMASS databases (e.g., Navy, DHRA) are directly accessible to off-site contractors from internet.

4. In addition to the eMASS account itself, users must be assigned to specific “roles” within the various “systems” that give them permission to read and/or write information in the record. In general, an eMASS user can only “see” systems in which he/she has been assigned a role. (Note: at least one of the eMASS “instances” had less restrictive permissions in which all users had read access to all systems; to the best of our knowledge, that is no longer the case.)

3. eMASS now requires all users to log in at least once every 35 days; accounts left “dormant” for more than 35 days are automatically deactivated. If you have an account on more than one eMASS “instance” (e.g., Army and Air Force), you will need to log in at least once every 35 days on each instance.

2. eMASS also enforces an “inactivity timeout” for logged-in users. If you do not click on anything or type anything for 30 minutes, your session is terminated and you will have to log into eMASS again in order to continue your work.

1. If you have an eMASS account, you should periodically receive e-mail messages from DISA informing you of planned outages, system upgrades, etc. Please read these carefully. NOTE: Do not access eMASS during any announced outage period; you may be able to successfully log in, but information you enter may not be saved!

NIST SP 800-53 Rev 5 - Big Changes Coming?

NIST SP 800-53 Rev 5 - Big Changes Coming?

By Lon J. Berman, CISSP 

As you probably know, the “catalog” of security controls used in RMF is derived from NIST Special Publication (SP) 800-53 Rev 4. What you may not know is that NIST is hard at work on SP 800-53 Rev 5.

The reaction to this news on the part of many people involved in the RMF process is likely to be concern … or even fear! Will extensive re-work need to be done to adapt our RMF packages to the new control set? Will new or revised documentation artifacts … or even system implementation changes … be required in order to comply? The more cynical among us may even be thinking “Just when we’re beginning to get our arms around this stuff, they’re going to change it and mess us up again!” The bottom line is we won’t know for sure until the document is published and we all get a chance to carefully analyze its contents. Until then, however, there are many factors that should lessen our concerns about the potential for major upheaval.

First of all, it’s important to understand the NIST publication process and to do that we need to understand what NIST is all about. A key element of NIST’s mission is private sector outreach, and part of the way they achieve that mission is by engaging outsiders in the publication process. An Initial Public Draft (IPD) is published, followed by a period during which comments can be submitted, leading to the publication of additional drafts, and, ultimately, a final document. This stands in sharp contrast to most DoD publications that are close-held until final publication, at which time they are “lobbed over the wall” at an unprepared audience.

For NIST publications, it typically takes several months from the IPD to the final document. We have yet not even seen an IPD of SP 800-53 Rev 5. It was originally scheduled for release on 28 March 2017, but, according to a NIST announcement, that has now been delayed due to “internal review” (they hope to publish the IPD “in the very near future”). If we assume the IPD is released in April or May, it is likely the final document will not be published until November or December.

In order to fully utilize this revised SP 800-53, NIST also needs to publish a corresponding revision of SP 800-53A, with assessment procedures matching the new control set. The IPD of this document is currently slated for December of 2017, which would push final publication well into 2018. 

Before the new 800-53 and 800-53A can be adopted by DoD, several additional steps must be completed, including:

  • Publication of a revised edition of CNSSI 1253. The level of effort for revision of CNSSI 1253 depends on the number of substantive changes to the controls in SP 800-53 Rev 5. Unfortunately, there is no visibility into the CNSS publication process; we’ll only know the revised document is done when it appears on the CNSS website!
  • Incorporation of new/revised controls into the eMASS database. This would be DISA’s responsibility and would only occur once the NIST and CNSS documents have been finalized and published.

In other words, we are probably looking at very late 2018, or beyond, before DoD system owners will need to address any of this in their RMF packages.

In their announcement of SP 800-53 Rev 5, NIST gives some insight into the new content we can expect, and much of it will not materially affect the controls.

Here are some examples:

  • The phrase “information system” will be replaced by “system” in order to make the document applicable to a wider variety of systems, such as industrial and process control systems, cyber physical systems, weapon systems, and even “Internet of Things” (IoT) devices.
  • The wording (but not the intent) of the controls will change to make them more “outcome based”. For example, a control such as “The organization will implement multi-factor authentication…” will now be stated-as “Implement multi-factor authentication…”.

The Program Management (PM) family of controls and the Privacy controls will be moved into a single  Appendix along with the 17 primary security control families.

  • The “federal focus” of the document will be de-emphasized to encourage its use by non-federal organizations such as state and local governments, private industry and academia.
Security Control Spotlight— “Naming” of Controls, Enhancements and CCIs

Security Control Spotlight— “Naming” of Controls, Enhancements and CCIs

By Kathryn M. Daily, CISSP

After assisting numerous customers with their RMF efforts, we have seen several instances of confusion arise concerning the “naming” or “numbering” of Security Controls, Control Enhancements, and Control Correlation Identifiers (CCIs). We hope this short tutorial will help to clarify things.

Security Controls. Security Controls are organized into 18 primary families. Additionally, there are 8 families of Privacy Controls. Each control family has a unique two letter identifier, such as AC for Access Control, AT for Awareness and Training, etc. Controls within each family are sequentially numbered, thus the Controls in the AC family are named AC-1, AC-2, AC-3, etc. NIST SP 800-53 contains the complete “catalog” of Security and Privacy controls. The System Categorization (Low, Moderate or High for Confidentiality, Integrity and Availability) determines the precise set of controls applicable to a particular information system.

Control Enhancements. Control Enhancements provide additional protection in the same general subject area as the control to which they “belong”. The System Categorization determines the precise set of enhancements applicable to the information system. In NIST SP 800-53, the Control Enhancements are presented just below the description of each Control, and are sequentially numbered. Control Enhancements are named with the name of the control, followed by the sequential number in parentheses. For example, the Control Enhancements that “belong” to Security Control AC-2 are named AC-2(1), AC-2(2), AC-2(3), etc. It is important to understand that, within RMF, Control Enhancements are treated as if they are simply additional Security Controls.

Control Correlation Identifiers (CCIs). CCIs roughly correspond to Assessment Objectives, as documented in NIST SP 800-53A. Each Control is “broken down” into one or more CCIs; only when all CCIs for a particular control are assessed as compliant will the control as a whole be considered compliant. NIST SP 800-53A names the assessment objectives by the portion of the control text from which they are derived. So, for example, AC-2 has assessment objectives named AC-2(a)[1], AC-2(a)[2], etc.

DoD, specifically eMASS, does not follow the naming convention of NIST SP 800-53A. Instead, assessment objectives (and therefore CCIs) are sequentially numbered for each Control or Control Enhancement. For example:

  • Assessment objectives (CCIs) for AC-2 are named AC-2.1, AC-2.2, AC-2.3, etc.
  • Assessment objectives (CCIs) for control enhancement AC-2(1) are named AC-2(1).1, AC-2(1).2, etc.

People sometimes get confused between the nomenclature for control enhancements, which use parentheses, e.g., AC-2(1), and the nomenclature for CCIs, which use a period or dot, e.g., AC-2.1. It becomes even more confusing when we are talking about CCIs that belong to a control enhancement, where both nomenclatures are used together, e.g., AC-2(1).1.

Also confusing at times is the notion of overall compliance. Controls and Control Enhancements are treated as completely separate entities when it comes to compliance. A control itself can be compliant, while some enhancements are compliant and some are non-compliant. By contrast, an individual Control or Control Enhancement is only considered as compliant when all of its CCIs are compliant.

BAI Announces eMASS Training Program

BAI Announces eMASS Training Program

By P. Devon Schall, CISSP

We are pleased to announce that eMASS training will now be available from BAI to complement our RMF for DoD IT training program.

Course Content

Our initial course offering, eMASS eSSENTIALS, is a one-day session in which we provide “how to” guidance for the most commonly-used eMASS functions, including:

  • System Registration
  • Security Controls and Test Results
  • Artifacts
  • Asset Manager
  • Plan of Action and Milestones (POA&M)

Who Should Attend

eMASS eSSENTIALS is open to all students with an interest in eMASS, particularly those who have previously completed RMF for DoD IT Fundamentals and RMF for DoD IT In Depth classes.

Students who have not yet attended RMF training are encouraged to inquire about discounted pricing for a training package that includes RMF for DoD IT Fundamentals, RMF for DoD IT In Depth, and eMASS eSSENTIALS.

eMASS eSSENTIALS includes “simulated live operation” of eMASS, however students are not required to have an eMASS account, or even a DoD Common Access Card (CAC), to attend.

Delivery Methods

eMASS eSSENTIALS will initially be offered as an online, instructor-led class, using our Online Personal Classroom™ technology. 

eMASS eSSENTIALS will also be available as a “Friday supplemental class” to organizations wishing to obtain “on site” RMF training for a group of students.

Learn More

For additional information on eMASS training, including initial dates for eMASS eSSENTIALS, please call BAI at 1-800-RMF-1903 or visit https://register.rmf.org

RMF and the Cloud

RMF and the Cloud

P. Devon Schall 

Probably the most talked-about concept in information technology today is cloud computing, often simply called “The Cloud.”

According to the National Institute of Standards and Technology (NIST), cloud computing is “a model for enabling ubiquitous, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.”

For the past few years, departments and agencies across the government have been aggressively pursuing “migration” of systems and applications to the cloud in order to save money and “deliver public value” by increasing operational efficiency.

Moving away from traditional data centers and into the cloud provides a variety of challenges, particularly in the area of information security landscape.

In a survey recently conducted amongst IT professionals, the top three rated cloud issues were security, availability, and performance. These concerns impact the level of trust consumers have with their data existing in a cloud environment.

The top seven cloud security risks and summaries as published by Cloud Security Alliance are listed below:

  • Privileged user access. Sensitive data processed outside the enterprise brings with it an inherent level of risk
  • Regulatory compliance. Cloud computing providers may be hesitant to undergo external audits and security certifications
  • Data location. The customer probably doesn’t know exactly where their data is hosted
  • Data segregation. Data segregation. Data in the cloud is typically in a shared environment alongside data from other customers creating confidentiality concerns
  • Recovery. A cloud provider should be able to tell what will happen to the data and service in case of a disaster
  • Investigative support. Investigating inappropriate or illegal activity may be more difficult in the cloud computing environment
  • Long-term viability. Data and logging should remain available even after services are discontinued

The federal government has taken steps to mitigate these risks and concerns in order to facilitate cloud migration without compromising security.

The Federal Risk and Authorization Management Program (FedRAMP) is a government-wide program that provides a standardized approach to security assessment, authorization and continuous monitoring for cloud products and services. FedRAMP utilizes a baseline set of agreed-upon standards and includes independent evaluation of cloud service providers by authorized Third Party Assessment Organizations (3PAOs).

Sounds an awful lot like the Risk Management Framework (RMF), doesn’t it? In fact, the “baseline set of standards” used by FedRAMP is derived from the very same “security controls catalog” used in RMF.

In the DoD world, the Defense Information Systems Agency (DISA) has established its own cloud authorization program that is essentially an enhanced version of FedRAMP.

Numerous resources exist to support these efforts. The Cloud Computing Security Requirements Guide published by NIST is an invaluable resource in reviewing and ensuring adequate system hardening. DISA Security Technical Implemental Guides (STIGs) are also utilized to verify the risk and threats listed above mitigated.

What is the relationship between RMF and the Cloud? It depends on your perspective.

Cloud computing service providers such as Amazon GovCloud typically undergo an RMF-like authorization process such as FedRAMP or the DISA cloud authorization RMF and the Cloud from Page 1 process. This results in formal authorization by the government, very similar to the RMF Authorization to Operate (ATO). Typically this authorization will include a suite of inheritable controls.

Application owners developing new software for deployment to the cloud, or those migrating existing applications from government data centers to cloud service providers, will follow the normal RMF life cycle leading to ATO. The process will be facilitated by inheritance of controls from the cloud service provider. Typically, control families such as Physical and Environmental, Media Protection and Maintenance can be inherited by the application owner.