afeld
commented
5 years ago My responses:
There are a plethora of examples/templates out there
Certainly possible that the finding is actually "people don't know where to find examples, if they do exist." That said, I've asked around and haven't gotten much.
Small clarification: the common complaint was not having control implementation narrative examples. For templates, I just meant to point out the inconsistency that some agencies provide them, while others don't.
you can point them to iassure
Interesting - I didn't know about that! The intended use of those documents is a bit unclear to me.
The user story that FISMAtic is trying to solve for is "As someone without [much] compliance experience going through an ATO, I want to know how to create my ATO package so that I can launch my system as quickly/painlessly as possible." While I like that the I-Assure templates take a questionnaire approach, not sure that they solve the "what do I put in each box of the SSP template I was handed?" problem.
tools like Xacta have plenty of templates available within the application itself
Indeed. That said, not every agency has a tool like Xacta, and even if they do, they may be under-leveraged. "Why" is a somewhat open question.
Many find these templates or someone else’s SSP and merge the two for anything they don’t understand and pass it off to a compliance team.
Totally. I'm trying to solve for the problem of SSP authors acting in good faith but being overwhelmed by the process. I have a hypothesis that a) authors are more likely to have access to one past SSP than multiple, and b) if you only have one example, they're more likely to match it exactly. My thinking is that having multiple (easily comparable side-by-side) allows them to see the range of responses, and therefore they'd be more likely to put in what's actually appropriate for their system.
Bottom line templates can be dangerous if not used properly.
Do you mean examples? Anyway, totally.
In many cases the tech writers do not understand organizational risk management or security, but they know how to assemble (copy and pastes) an A&A package.
Framing this and putting it on my wall.
the ISSOs are separated from the mission five times over. They have limited access, no authority and often have never met the team face to face
80% of the time they haven’t even read the requirements they are supposed to be enforcing
Yeah, heard that from others as well. Yikes.
compliance teams are sometimes correct in their stance of rejecting a poorly written package
Totally agree. The goal of this project is to make it easier to write good ones.
many of the folks that are self-proclaimed ISSOs or security analyst, might not exactly have the depth and breadth of experience to solve this problem
Yep, trying to get a range of folks.
the large majority of the controls are non-technical. Just because they are not technical does not make them any less important.
Very good point.
I have tried to help organizations address this problem for years
You have way more experience in this area than I do, no question!
Anyone who has attempted to achieve a federal Authorization to Operate (ATO) can appreciate the irony of the name “Step 0.” It is not uncommon to spend years in the Assessment and Authorization (A&A) process. With no ATO to show at the end of this investment, it is no wonder that some system owners feel they are living in Step 0. https://multimedia.telos.com/blog/the-irony-of-rmf-step-0/
Love this.
Feedback from Gianna Price, Solutions Architect at Telos, is below. Cross-posting here from email, with her permission. Huge thanks for all the wisdom, Gianna!
I read through your research summary which provoked a couple thoughts I wanted to share. First I was surprised that so many said they couldn’t find examples. There are a plethora of examples/templates out there, many agencies even have their own. For those that don’t you can point them to iassure, who for some time have put out RMF templates free for government use. In addition, tools like Xacta have plenty of templates available within the application itself. Even with these templates, organizations need to identify how they are actually implementing security. Many find these templates or someone else’s SSP and merge the two for anything they don’t understand and pass it off to a compliance team. If your template says one thing and during an interview the response is something different, the compliance teams will highlight the discrepancy and require it be resolved before progressing. Bottom line templates can be dangerous if not used properly.
This brings me to my second point which is that the government compliance industry has morphed the role of the ISSO into a tech writer; but still give them the responsibility of the ISSO. This is the person that holds the majority of the tactical responsibility for the package and is the interface between secops, PMs, assessors and AOs. In many cases the tech writers do not understand organizational risk management or security, but they know how to assemble (copy and pastes) an A&A package.
Because we have been so compliance focused over the years these package producers have become their own industry; unfortunately neither the tech writer nor the system owner realize that these individuals are not ISSOs. If you read DoD and other regulations, the ISSO should be part of the day to day security management. They should have access and authority to impact the security of an information system. ISSOs should be embedded within the organization and have a direct relationship to the ISSM and System Owners. In this capacity it would make sense that an ISSO have the majority of the information needed for an A&A package.
However at organizations we both know, and others, the ISSOs are separated from the mission five times over. They have limited access, no authority and often have never met the team face to face; yet these are the individuals we hold responsible for describing how security is implemented, maintained and budgeted for? The sad thing is that many of these tech writers truly think they are serving as an ISSO. The closest thing they do to being a true ISSO is reviewing scans on a monthly basis where they create a service now ticket for its remediation. This doesn’t really count as ISSO work as they do not have access to the scan engine itself, they only get the output, which may or may not be accurate, that someone else has generated. They track the progress of others that are implementing security and blindly regurgitate it into the SSP and other artifacts.
As a Cybersecurity branch manager, in a previous life, this ISSO situation is a real issue when trying to staff your organization with security experts. In search for a true ISSO, I have interviewed dozens of CISSPs/Sec+ certified that do not know the first thing about security; 80% of the time they haven’t even read the requirements they are supposed to be enforcing. What they do know is their lasts organization process for filling out templates. I knew better than to hire a tech writer for a security position, but many system owners/PMs do not. They putt all their ATO eggs into the very unqualified ISSOs basket. Compounding the issue is the workforce shortage; System Owners are spending a fortune of money on tech writers that happen to have CISSPs or Sec+ certifications, with no ATO to show for it.
I am highlighting this issue for a couple or reasons. First, poor input is poor output. We do need to acknowledge the compliance teams are sometimes correct in their stance of rejecting a poorly written package. Second in your polls through the community I think it is important for you to know that many of the folks that are self-proclaimed ISSOs or security analyst, might not exactly have the depth and breadth of experience to solve this problem. Lastly, as we move forward in automating compliance we need to make sure that we are not just building a better template. As I am sure you are coming to find, the large majority of the controls are non-technical. Just because they are not technical does not make them any less important. Templating compliance can be dangerous as it doesn’t not implement/continuously assess security.
...
Here are two [blog posts] that might help paint the picture of perception and reality in this field. A little soap boxy, but like you I have tried to help organizations address this problem for years. I appreciate your efforts to try to solve this complicated issue and will continue to monitor the progress.