When Esteban cloned the compliance package for a NZ Office in the training it occurred to me that we could go really wrong with Eramba if we don’t plan super well.
We treat our environment as separate systems for purposes of Accreditation so we have dozens of Certified Systems under going various compliance works on a continuous basis.
We accredit our Official network separately from our Protected Classified network, under that we accredit a system hosted by us but shared be lots of other entities separately from a Data analytics service we also offer externally.
The plan has always been to Layer Accreditation along the lines of …
Management and Compliance
That way each system can inherit from the layer below.
As I see it there are a few ways to do this:
have one control set and assume compliance of all systems and enter exceptions tagged it with the Asset (Windows Server 2016 / SQL / CRM etc) this would mean the whole system would show the non compliances and a filter of exceptions for each asset tag would build a SOA a bit manually.
Clone a control set for each system and deal with the complexity of updating the same framework a few dozen times when updates occur. We currently get Monthly amendments from our compliance body ISM 2018 from the ACSC. I suppose we could hack the database to update some of these and where they add controls just import an incremental CSV as required to each set.
a third way I have not thought of … Which is where you learned folk come in.
Have I over thought the problem? What do other people do?
#Planning #NewInstall #DontWannaMakeItHard
%100 true - in 10 years doing this i have seen many people complicating their implementation by simply not planning it well !! is not about people having sufficient experience in grc ,etc … nothing at all … is just that switching from spreadsheets to a grc system is like switching from a bicycle to a car … similar, but different.
i understood until here:
then i kind of lost it , you need to show a compliance report for each layer described above or within each layer described you certify different bits under different set of requirements?
The logic in eramba to decide if you need one or more “compliance packages” generally (no written in stone) is:
1- you have different compliance packages … iso, pci, etc under the same or different scope (your layers). This is the obvious one.
2- you have the same compliance package (requirements) across different scopes (assets, processes, etc whatever is the scope), the typical example is you run ISO in different countries. here you have a few options:
if your internal controls (as we call them in eramba) in UK and NZ are the SAME ALL THE TIME, then you need ONE compliance package “ISO Global”. The report of that compliance package should serve both locations as they are run exactly the same way.
since the above is rarely the case, you end up needing two compliance packages (NZ and UK) and then sometimes a given internal control will serve both locations (when the testing methodology is the same) and sometimes you will need different internal controls for the same requirements simply because things are done differently in the UK and in NZ.
Example Req. 11.1.1 : in UK we dont have our own offices so physical controls are different from NZ where we do have our own offices. you will then have two internal controls “UK CCTV” and “NZ CCTV”.
- splitting into two compliance packages will give you two different “Item Reports” , that is sometimes useful … lets say the UK managers run things like shit and you want to put that in evidence
either way… it seems to me you are doing exactly what i would … plan before clicking.
Okay we use one framework the ISM all systems are assessed against this. (Import CSV) https://www.dropbox.com/s/at6jvpuwj8w3p1m/ISM2018Master.csv?dl=0
Different teams are responsible for different systems but my team is responsible for Certification and Accreditation etc.
We have a team that manages Nutanix, AWS / Azure and On Prem vmware
We have a SOE team who build the Windows Platform, a linux one too
We have Database and Platform Services
Analytics Data Platform
AND OF COURSE our Business goes and procures solutions as well as engages with PaaS and SaaS providers
Now I do like the idea of separate compliance packages because we do have a dozen or so “Systems” and the System owners are quite different in their appetite for compliance but they do ALL have to comply with the same framework (ISM 2018).
Where I don’t like it is updating the framework a dozen times (at the moment a month) although mounting the Maria DB and Global Search replace “COULD” make that easier.
Perhaps one Compliance Package where non compliance is tracked as Exceptions
Actually I think I may have just talked this through on my own …
How about this …
One Compliance Package ISM 2018 (although I see SCF as a possible way to leverage one and comply with many)
Internal Controls tagged with responsible team SOE, Platform, Logistics and Network etc
When an internal control goes RED everyone will be RED but we can easily see how, why, if risk assessed what ever
All Systems will inherit the compliance of each other so when we create a SoA all data will be there and we might just a an Internal Control for say Server Whitelisting - WInSOE using DCS and Applocker with another one Server Whitelisting - Linux with the SE Linux config so when Whitelisting ISM Control goes RED we can tie back to the Internal Control managed by the correct team.
Does this sound like a Better Practice?
Have you found your answer? I’m very much interested in this topic as well.
There was a thread long ago here : Feature - Asset to Controls / Policies (planned for r46)
Perhaps, it’ll give you more ideas…