It was discussed above how automating the typical stages of audits simultaneously results from and at the same time, helps to increase the maturity of the process as a whole. Having implemented the appropriate solution, some organizations may think that is the end of the matter – all that is left to do is keep the process running. Tasks are automated, monitoring is underway, and data is organized.
In fact, this is just the beginning. Organizations are moving to the next level of cyber security maturity when they stop doing audits “because the authority forces them to do this” and realize that this tool can be used to proactively respond to problems.
Internal audits can be organized in many different ways but quite often they begin with the fact that, as cyber security employees gain the experience they start to form their own, in-house, standards. As they learn the various regulatory requirements, they feel the need to formulate a metric for themselves that reflects the level of asset compliance without reference to specific external documents.
This is how internal standards and compliance assessment methodologies are born.
One branch of the global presence telecom company used a primitive IRP system with a very limited functionality. Since the company is a managed security service provider, arose the need of a new, more flexible platform with a significantly greater range of functions. After a series of negotiations and the PoC project, the Defensys SOAR was chosen as a core solution.The Provider offers its SIEM and TI systems to each customer and, depending on the customer infrastructure, one company can have several platforms. For that reason, Defensys software had to be integrated with all installed systems.
The Provider’s client database was connected with the Defensys SOAR and stored information is being synchronized with custom assets. Due to this, when an incident occurs, the Provider has very exact information, which SIEM system it comes from, which company is involved, and all the data is already stored and up-to-date in the client’s card for further processing. It made possible a customized incident notification via, for example, ITSM systems or messengers. As a result, it became a very effective tool with the workflow for a particular incident type created exactly for the Provider’s needs.
Moreover, the Provider uses well-liked mailing for subsequent reporting involving several mail-boxes.
During the course of compliance assessments, auditors inevitably record a certain number of violations.
The main mistakes that can be made at this stage are:
– Treating a violation/issue as one of the fields to be filled in with text during the audit.
– Treating issue input as the ultimate goal of the audit.
Why should all detected issues be treated as a separate entity within the audit framework? First of all, for proper monitoring, the comment must have at least the following attributes:
– Status
– Creation date
– Elimination date
– Author
– Responsible staff
– Completion date.
This is already more than something that will comfortably be stored within one, two, or three fields. However, the list of required attributes does not end there. With respect to the comment, it is also important to record:
– For which asset was it initiated?
– In the context of which audit?
– What requirement was violated?
– What evidence was attached ref the violation?