RMF Lesson Learned

Speaking from my own experience I would say the following are my biggest lessons learned from working on large RMF projects:

• Know the risks of the system
• What is the Impact if the system goes down
• Fit the RMF Controls to the System
• Keep All stakeholders in the Loop

Know the risks of the system.  As you go into an RMF project you should get to know the system and/or network environment well enough to understand not only the functions of the system and its assets, but where the known and potential vulnerabilities may be.  You will also need to do research on the most likely threats (internal and external to the system).  If you know basic characteristics and functionality of the system, vulnerabilities and likely threats to the vulnerabilities of the assets, you will be able to determine the qualitative or quantitative risks.

Lesson I Learned:  Risk assessment is a continuous process.  

What is the impact if the system goes down.  Once you have an idea of the risks to the asset, you will need to consider the impact to the organization and/or mission if the system does have its confidentiality, integrity or availability compromised.  How long can the system lose connectivity?  And what happens when availability is lost?  Who is contacted if availability is lost?  Who is the POC if secrets a leaked?  What is the most important area of protection on the system?  Is availability of the system more important than confidentiality and integrity?  You need to focus on the value of the data to the customer and the data owner.

Lesson I learned:  Knowing the value of the data is the key to understanding the system itself and what needs to be protected.

Fit the RMF Controls to the system.  Once you know the systems asset characteristics, vulnerabilities,  most likely threats, and impact if the system goes down, you will have a better idea of what controls will be most useful.  You will have a solid argument on WHY certain controls can be skipped while others must be met.  AND you know the security posture and the security classification of the system.  The classification of the system comes from the Information System Owner.  Security Professionals can make recommendations, but we are not the decision makers, we don’t own the system so its not our call. YES, we are sometimes called upon to help make a decision or even develop a recommendation, but the final decision is in the hands of the System Owner.  Classification of the system will give a better idea of the importance of the confidentiality, integrity and availability of the data making it easier to select NIST 800-53 controls.  Once you know what controls need to be applied to mitigate known vulnerabilities, you have armed yourself with some facts to take to others involved in the project.

 Lesson I learned:  The goal is not to apply every security control, but to make the system secure.

Keep All Stakeholders in the Loop.  Who are stakeholders?  These are the individuals and organizations with a vested interest in the success of the project as a whole.  The term stakeholders is not always used.  Sometimes its called RMF Team and it used to be called DIACAP Team.  What ever you call it, this group includes but is not limited to:  The System Owner, Information System Officer, Information System Security Manager, Information System Security Officer, Technical staff, User representative.

Information System Owner is the person(s) controlling the budget of the project.  They are usually too busy to attend every meeting but without them there might not be a political will to continue.  The are sometime represented by the User representative who is mostly concerned with maintain functionality of the system as security controls are applied.  The Information System Security Managers (ISSM) involvement is managing the work of the Information System Security Officer (ISSO), making recommendations to the system owner and/or upper management who controls the budget.  Sometime the ISSO and the ISSM are the same person.  The ISSO works directly with the technical staff to apply security controls or produce/find security artifacts to support evidence of security controls.  The technical staff might consist of a system administrator, a system security engineer, a network/firewall engineer or whoever is going to be applying security controls on the system.

 Lesson I learned:  The more the stakeholders know about what is going on, the better.

How do you inform the RMF Stakeholders need to know?

Meetings, webcasts, one on one, emails or some combination of all.  You need to be straight forward and realistic with all parties involved.  For example, if there is a need for an approved enterprise firewall that will cost no less than 10,000USD, don’t try to sugar coat this fact by telling them they can get a cheap firewall from BestBuy.  Be honest about how much time the RMF process will take.  Its a lot of work and a lot of time it depends on others getting you the right documentation so you have to factor that in the total time.  If you don’t know, find out.  Do all your homework so that you can let the team know the details of the project, what is driving the need to the RMF, and the impact if it is not completed.

Lastly (and this is important) make sure the team knows that you are on their side.   They need to know that you are part of the team and want to enable the functionality in a secure way.  For some reason, some security professionals don’t care about customer service and want to bite the hand that feeds them.  You can give good service and good security.  In other words, you can be a security pro without being a DICK!