I’m evaluating Eramba. I’m currently running Community in my home lab, and hoping it will meet our needs so we can buy and deploy Enterprise at my work.
We are doing NIST RMF. We have a NIST 800-53 control baseline, (security controls) which I’ve uploaded as a Compliance Package. We have ~30 information systems (our website, our internal training platform, our email system, etc.) I’ve created these as Assets, with the Asset Type of Information System.
I need my team to document how each information system meets each control. The way our website achieves access control is different from how our email service does, which is different from how our training platform does. So each information system needs its own implementation statement. Then I need another person to assess each implementation statement annually.
How do I assign the one Compliance Package to multiple Information System Assets, such that each Asset has distinct answers to each control requirement?
I’m new to Eramba and this is a very interesting inquiry. From a CISO perspective, I usually produce one master document for a control and include all the systems in the document. The reason is because controls are generally inquired about as it relates to a risk inquiry on insurance or a risk assessment. The answers are generally yes all systems, not all systems, or not applicable. Therefore the document must address an inventory of all the systems in that classification and how risk is managed for those systems.
If Eramba can do it, it would be useful to have something like tiers under a control and each item in tier 2 (for example) to be each system with the description of how it satisfies risk management for that control. I don’t know how best to do that inside Eramba though.
Is this forum the best way to ask this sort of question? Looking at the pricing page, it seems like this would be quickly sorted out by buying a Compliance Management workshop. But I don’t want to get all the way through buying and deploying Enterprise, only to find out this isn’t possible. Thanks!
The way you’d want to structure it would be to have a compliance package for each system in scope. You’d likely have to create custom fields (Enterprise feature) on the Compliance Analysis for the SSP narrative describing each component of the system. I’d also think that you’d want to tailor the compliance packages where there’s one package for “shared service” style controls that apply to all (or, a portion of systems), though, doing more than one shared service group might get unwieldy. For example, if AT and PE were the same for every single application, do a single compliance package and document once, and leave them out of the app specific package. Then when reporting you’d merge them back together into the SSP.
The other place where you’ll have some difficulty will be with reporting, especially if you need it in some form of government prescribed RMF template. Reporting should get you more or less a table with the columns of the compliance analysis grid that you want. If you need something more custom, or injected into a word template, you’ll need to hit the API and build it yourself (or, with the 3.31 release, your buddy Claude could use the MCP server to do this).
Final thing to keep in mind - the concept of what a NIST “Control” is and what eramba considers a “Control” (aka “Solution”) is a bit different. The NIST “Control” is a “Problem” in view of eramba. See Problems & Solutions. Eramba controls are more aligned with the SSP narrative - things that you do that then relate to your problems (NIST controls) to solve them. You might have 3 separate controls you do that map back to one NIST requirement or you might have 1 control map back to 23 NIST requirements. The compliance analysis screen is where you determine how compliant you are when considering the associated controls/policies. The key benefit of the controls in eramba is to make sure they’re operating, assigned owners, audited, and then reporting on the operating status against NIST/etc.
So if I have 30 systems, that’s 30 compliance packages. I’m concerned how we would validate the completeness of a given system’s compliance package at the time of the assessment. If a requirement changes, we need to manually change it 30 times. If we add new NIST Controls to our baseline, they need to be uploaded 30 times. (Or csv). Every new system means we need to import another CSV that is maintained outside of Eramba. Part of what I want from a GRC tool is assurance that nothing falls through the cracks. I fear this takes us away from managing it all with spreadsheets, but now we’re managing it with import-CSVs.
Just to add onto that - I would have come to the same conclusion as david.schroth.
If you want to document varying degrees of compliance for different systems all related to the same requirement from any standard, that would require multiple copies of that standard in eramba.
While it is doable, I feel it is wrong and Eramba is probably not the best tool to achieve this “per entity view”.
How we handle it is, that our “solutions” (eramba lingo) can be a company policy (a document mandating some level of encryption for all systems) plus a technical enforcement (e.g. a CSPM solution automatically enforcing no HTTP based endpoints on all cloud resources).
This might not be sufficient for system security plans as you stated.
As a side note: For a similar endeavor we also assesed “Microsoft Compliance Manager” for the same use case (evaluating many systems against the same standard). It felt a little better tailored towards this, however the standards inside weren’t up to date and also way too expensive to purchase, per standard.
Also it was completely missing the part about evaluating whether a certain internal control was actually followed or working.
We ended our trial of the MS solution, wrote a few SSPs in Word (this was before the AI year of 2022 mind you) until we could reduce the number of SSP-required systems. Finally for the standards these days we found eramba to be a great match to document our general compliance.
Per-System Documentation is currently handled in the CMDB, which we beefed up with a couple of extra data fields.
Stil subbed to this thread, to learn, what the eramba OGs have to offer in this regard! Fingers crossed they have something good up their sleeves.
How often are you adding new NIST controls? It takes them 5+ years to rev 800-53 from the time they get the itch to the time they scratch the itch…
Regardless, even if you did add a new control, you have to go through that exact exercise for each of your 30 systems regardless of whether it’s in Eramba or not. How else can you conclude that the control is implemented and described in your SSPs if you don’t?
For compliance packages, you have to have a change control process for them so they’re done in an orderly manner. You won’t be importing CSVs for those edits, you’ll be adding a new Package Item. Maybe with the incoming API refresh, they’ll add the ability to add/edit compliance items, which would make the bulk insertion a bit better.
There are also plenty of read APIs for all of these - if you’re concerned about consistency between packages/manual entry errors, you could consider assembling a script to run against the API and confirm all of the packages map (basically, loop on through them) on a scheduled basis.
Ninja edit: Appears 3.31 will have api/v2 included, above was written based on what I see in 3.30 api/v1.