Security Control Spotlight— Inheritance from a FedRAMP Approved CSP

Security Control Spotlight— Inheritance from a FedRAMP Approved CSP

By Kathryn M. Daily, CISSP, RDRP 

In a previous issue, security control inheritance from an external system hosted at a departmental or agency data center was discussed.  In this article, we are going to discuss inheritance from a FedRAMP Approved Cloud Service Provider (CSP) such as Amazon Web Services (AWS), Microsoft Azure, etc.   

FedRAMP is an assessment and authorization process for cloud computing products and services.  Federal agencies have been directed to use FedRAMP approved cloud computing products and services to ensure that a minimum level of security is provided by the CSP. Like federal information systems, FedRAMP approved CSPs receive an ATO for a period of 3 years, and they go through the A&A process again, or when there is a major change.  As with inheriting from another information system, the benefit of using a FedRAMP approved CSP is that it eliminates redundant validation of compliance—the compliance of the 

“providing system” (CSP) automatically inures to the benefit of the “receiving system” (hosted customer system). 

This inheritance makes YOUR A&A process much less painful.  For one, Maintenance, Media Protection and Physical and Environmental are completely inherited.  Prior to FedRAMP, the Security Control Assessor (SCA) had to visit the data center to check the “gates, guards and guns” every single time, even if that specific assessor had previously visited that data center.  That is no longer necessary.  The FedRAMP ATO takes care of all of that.  In addition, there are several “shared controls” where the CSP provides the capability to fulfill the control, and provided that the customer configured the mechanism appropriately, the control is compliant.  One example of this is the Access Control family.  AWS provides a tool called Identity and Access Management (IAM) that enables you to securely control access to AWS services and resources for your users.  IAM provides the capability to be compliant with much of the Access Control family.  

AWS also provides CloudTrail, which provides the capability to be compliant with most of the Audit and Accountability family. You can obtain the System Security Plan for the CSP you choose, which documents the details of the implementation for each of the shared and inherited controls. 

At you can see all available CSPs, their service models (SaaS, Iaas, PaaS, etc) and the impact level (high, moderate or low). Currently there are 67 CSPs that are ‘In Process’ and 86 that are approved.  You can also fill out the Package Access Request Form which will get you a copy of their FedRAMP artifacts (SSP, ATO, etc).  Keep in mind a government employee will need to request the package on behalf of a contractor

Registered DoD RMF Practitioner (RDRP)

Registered DoD RMF Practitioner (RDRP) 

By Lon J. Berman, CISSP, RDRP 

BAI Information Security is pleased to announce the upcoming launch of a new program called Registered DoD RMF Practitioner (RDRP) - a network of security professionals specializing in supporting RMF in DoD programs. The requirements to join RDRP are very minimal: 

Step 1: Attend 4 days or more of RMF for DoD IT training. 

Step 2: Complete the 50 question “RMF for DoD IT Competency Test” with a passing score of 70%. 

Step 3: Remit the initial credentialing fee (No cost if you’ve completed BAI’s RMF 4-day training program within the past 12 months).  

Your next question may be, why would I want to join the RDRP registry? We feel that being part of the RDRP registry not only adds value to your resume, but it also shows employers and government officials that you have a comprehensive understanding of RMF as it is implemented within DoD.  

Another dynamic of RDRP that is worth thinking about is how it relates to The National Initiative for Cybersecurity Education Workforce Framework 

(NCWF), which is currently in an early draft. The mission of NCWF is to enhance the overall cybersecurity posture of the United States by accelerating the availability of educational and training resources designed to improve the cyber behavior, skills, and knowledge. A major part of NCWF is to define the cybersecurity workforce and identify the training and professional development required by mapping cybersecurity skills to seven cybersecurity categories. These categories are: Securely Provision (SP), Operate and Maintain (OM), Oversee and Govern (OV), Protect and Defend 

(PR), Analyze (AN), Collect and Operate (CO), and Investigate (IN). BAI’s courses and RDRP map directly to the family Securely Provision (SP) which includes the specialty area of Risk Management (RM) mapping to a variety of in demand work roles. Over 20 agencies and federal departments worked in partnership to develop NCWF, and I imagine, it will play a more significant role in career development and qualification once a final draft is issued.   

For additional information on RDRP, keep an eye on BAI’s website and follow the BAI LinkedIn page for announcements.  For more on The National Initiative for Cybersecurity Education Workforce Framework 

(NCWF), review Draft NIST Special Publication 800-181 or join the NICE Working Group (NICEWG) hosted by NIST.  

Cybersecurity Framework (CSF) as it relates to Risk Management Framework (RMF)

Cybersecurity Framework (CSF) as it relates to Risk Management Framework (RMF)

By P. Devon Schall, CISSP, RDRP 

I recently attended the Cybersecurity Framework (CSF) Workshop from May 16-17 at NIST in Gaithersburg, Maryland. The workshop proved to be informative in relation to how government and industry are implementing the guidance issued by President Obama in Executive Order 13636. This EO outlines the responsibilities of Federal Departments and Agencies in Improving Critical Infrastructure Cybersecurity. President Trump’s executive order issued on May 11, 2017 titled, Presidential Executive Order on Strengthening the Cybersecurity of Federal Networks and Critical Infrastructure reinforced EO 13636 and directly referenced CSF. CSF is a complicated framework, the scope of this article will be to outline concerns about CSF as it relates to RMF.   

1. What the heck is CSF? I am just now learning how to do RMF, why is NIST throwing another three-letter framework acronym at me?

Rest assured, I had similar concerns. At a very basic level, CSF is not the same as RMF, and it is not a “rip and replace” of RMF. The writers of CSF assured me that RMF is not going by the wayside and it is a separate framework than RMF. CSF is voluntary guidance based on existing cybersecurity practices to help organize and manage risks. CSF is holistic and targeted toward federal agencies as well as the private sector. Similarities to RMF are a multi-step security lifecycle as well as common language. Additional technical information about CSF can be found in NIST Cybersecurity Framework Draft 1.1. 

2. How will CSF change RMF?

I asked this exact question to the folks at NIST. They indicated that those already doing RMF could voluntarily use aspects of CSF to strengthen their RMF activities, and we may see some aspects of CSF implemented in future updates to RMF.  

The future integration was described to me as “RMF with a CSF flair”.  I do not anticipate CSF to immediately impact RMF, but I do think we’ll see CSF language in NIST SP 800-53 Rev. 5.  

3. How will CSF impact my ATO?

At this point, RMF activities and current ATO’s will not be impacted by CSF. CSF is a framework targeted at strengthening cybersecurity posturing for organizations and has many overlaps with RMF, but it is not going to change your current pursuit of an ATO.  

Overall, CSF is an interesting framework, and it is encouraging to see the Trump administration recommending its usage. The framework is appealing as being holistic and applicable to businesses of any size. The initial draft is an approachable government document which I highly recommend reading.    

Continuous Monitoring Today—And Tomorrow

Continuous Monitoring Today—And Tomorrow 

By Lon J. Berman, CISSP, RDRP

Step 6 of the Risk Management Framework (RMF) is entitled “Monitor Security Controls”. Many security professionals would argue it is the most important step, since monitoring is what transforms RMF from yet another “point in time” evaluation to a true life cycle process. It has been more than three years since the official adoption of RMF, yet no Information Security Continuous Monitoring (ISCM) policy, procedure or guidance has been published by DoD.

Security control CA-7 states:

“The organization develops a continuous monitoring strategy and implements a continuous monitoring program that includes:

a. Establishment of [Assignment: organization-defined metrics] to be monitored;

b. Establishment of [Assignment: organization-defined frequencies] for monitoring and [Assignment: organization-defined frequencies] for assessments supporting such monitoring;

c. Ongoing security control assessments in accordance with the organizational continuous monitoring strategy;

d. Ongoing security status monitoring of organization-defined metrics in accordance with the organizational continuous monitoring strategy;

e. Correlation and analysis of security related information generated by assessments and monitoring;

f. Response actions to address results of the analysis of security-related information; and

g. Reporting the security status of organization and the information system to [Assignment: organization-defined personnel or roles] [Assignment: organization-defined frequency].”

For each of the Control Correlation Identifiers (CCIs) comprising this control, the RMF Knowledge Service provides the following Implementation Guidance and Assessment Procedure:

“Future DoD-wide Continuous Monitoring guidance to be published”

Many system owners (and independent assessors!) interpret this to mean CA-7 can legitimately be declared as “Not Applicable” pending publication of DoD-wide guidance. Is this really the end of the story (for now)? Can we just put the whole ISCM “thing” on the back burner until DoD finally publishes some guidance?

For the sake of your program’s mission … not to mention our Nation’s security … I sincerely hope not! That’s all nice to say, but how can you be expected to establish an effective ISCM program when there is no guidance available?

The answer is that, in reality, there is no shortage of available continuous monitoring guidance – both from DoD and elsewhere. And, beyond that, many technical tools that can be leveraged in support of your ISCM program are already available from DoD.

DoDI 8510.01 (RMF for DoD IT) lays out the system owner’s responsibilities for RMF Step 6 (Monitor Security Controls).

These include:

  • Determining the security impact of proposed changes to the system
  • Monitoring the system and environment for security-relevant events
  • Periodically assessing of security control implementation
  • Reporting significant changes in security posture to the Authorizing Official
  • Assessing security controls annually
  • Conducting remediation activities based on the results of ongoing monitoring and assessment activities
  • Updating the system POA&M on a regular basis NIST SP 800-37 provides additional guidance on Step 6 activities.

NIST SP 800-137, entitled “Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations”, is an entire volume dedicated to Continuous Monitoring. It covers topics such as: development of monitoring strategies and monitoring plans, selection of metrics and assessment frequencies, security status reporting, and monitoring program evaluation.

Other government publications supporting continuous monitoring activities include:

  • NIST SP 800-92, “Guide to Computer Security Log Management”
  • NIST SP 800-55, “Performance Measurement Guide for Information Security”
  • “US Government Concept of Operations (CONOPS) for Information Security Continuous Monitoring (ISCM)”, published by the Joint Cybersecurity Performance Metrics Working Group

DoD has developed numerous tools to support continuous monitoring. These include:

  • Assured Compliance Assessment Solution (ACAS) – an enterprise vulnerability scanning and reporting tool
  • Host-based Security System (HBSS) – a suite of commercial products that include malware protection and host-based intrusion detection/prevention
  • SCAP Compliance Checker (SCC) – a tool that facilitates scanning of operating systems and other software for compliance with DoD Security Technical Implementation Guides (STIGs)
  • SCAP benchmarks – content developed by Defense Information Systems Agency (DISA) to support STIG compliance scanning (using SCC) of various commercial software products
  • STIG viewer – software tool to facilitate “manual review” of operating systems, database management systems, web servers, etc., for STIG compliance

System owners are encouraged to leverage the above resources to implement a continuous monitoring program now. When DoD (finally) gets around to publishing their long-awaited Continuous Monitoring Policy/Guidance document, it will most likely take only minor adjustments to bring your ISCM program into complete compliance.

Between now and then, you’ll sleep better!

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

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.