This is how I do Cybersecurity. There are many ways to do… | by Vicente Aceituno Canal | The CISO Den | Oct, 2022

There are many ways to do cybersecurity. This is how I do it, and I call it Evidence Based cybersecurity management.

I don’t think I know more about cybersecurity requirements than the owners of the information. This is why I try to meet the needs of the business, formally documented as goals and targets. This is easier said than done.

I distinguish three types of stakeholders of information: Users, Owners, and Admins, that can either be part of the organization or of third parties.

I try to use a minimal set of concepts that user and owners of information also understand, in order to facilitate communication and reach agreements.

I need to be able keep track of actions in systems and protection cycles and cross check them with evidence of the associated business decisions.

Unfortunately systems don’t include features that provide the necessary business context for the actions performed in the system. For example, when an account is created, it may be because there is a new starter, but unless there is a ticket where an authorized person communicates the request for the new user account for the new user, I don’t have a way to know for sure if the creation of the account is malicious or benign.

Tickets, policies, procedures, reports, forms, meeting minutes, templates, emails, database records and other electronic records are all deliverables, I prefer to manage them according to a Knowledge Management Policy that results in a low effort to everyone involved to understand the status and ownership of tasks and documents.

I use deliverables as the unit of work, they are useful as evidence of the work performed, and it is easy to count them as metrics to include in reports. Cybersecurity reports are useful to understand the current cybersecurity situation, and trigger tasks and implement decisions that contribute towards moving towards a target situation.

I use success criteria at three levels: Overall, per Type of information and per Cybersecurity protection cycle. Business significant incidents happen when any these success criteria are missed.

The overall cybersecurity success criteria (aka Goals or Security Requirements) are the result of an agreement with the Owners of information are listed in a Information Security Policy, and the risks are listed in the Risk Register. I can gauge the business value of the cybersecurity activity according to the contribution to meet these goals.

I classify information according to the ownership, control and use being internal or external, and I list the associated success criteria in the Classification of Information Policy. I can also gauge the business value of the cybersecurity activity according to the contribution to meet these targets, and decide what activity is adequate for each type of information.

The Cybersecurity protection cycle success criteria is defined as having the fewest possible outstanding weaknesses and non-compliance items.

IT infrastructure is very complex. In order to understand this complexity, I model IT systems as follows: Information is contained in “information assets”, that I call assets or systems for short. Protecting the assets results in protecting the information in them, achieving the cybersecurity success criteria.

While some protection is well understood can be highly automated, most meaningful protection is performed, supervised or led by stakeholders of the assets who have the responsibility and the power to protect them. I collaborate closely and reach agreements with the stakeholders of the assets about how to best protect them. For example, owners of a system set the cybersecurity goals and targets applicable for the system they own.

I manage the protection of the systems using periodic management cycles with three phases:

• Discovery: Review if the list of assets is complete and correct.
• Verification: Review if the assets have weaknesses or are missing security features. For some types of assets, like operating systems of web application, there are weaknesses taxonomies like OWASP that greatly help with verification. Published catalogs of security features are harder to find.
• Remediation: Fix the weaknesses found

These phases should be performed using methods that are repeatable, comprehensive and independent of the practitioner. The three phases don’t need to have the same periodicity.

According to the exposure to public networks, the class of information and the stage of development of assets they may have different priorities. The cycles for higher priority assets will have shorter periods (Service Level Agreements) than for lower priority assets when separate protection cycles are implemented for each priority category.

During periodic cybersecurity management meetings I review the available Reports based on Metrics, make an assessment of the state of protection and threats (situational awareness) and take decisions for amendments of errors and mistakes, and improvements that are documented in Meeting Minutes, also facilitating keeping track of them. Failing to meet success criteria (goals, targets, expected results) trigger corrective actions, and this is why my management cycles are self-correcting. A complete cycle looks like this:

1. Work, performed according to policies and procedures is documented in tickets.
2. Metrics are collated, archived and represented in Reports.
3. Reports based on Metrics provide an interpretation of the meaning of the metrics (Satisfactory / Unsatisfactory) for Discovery, Verification and Remediation, giving situational awareness of the situation for managers (aka, are there any problems?)
4. Review of the results of past decisions, if they had the expected effects or not (aka validate hypothesis), found in the previous meeting minutes
5. Decisions to introduce new fixes or improvements, and their expected effects (aka formulate hypothesis), recorded in the Meeting Minutes, with each entry indicating: Findings of Assessment and Diagnosis​, Root cause​ found by Investigation, Action Possible Treatment Change or Improvement By Owner, Success criteria (expected result of the treatment), Complete By Date.
6. Fixes or improvements will normally lead to changes in policies and procedures, that document how work is carried out.
7. And the cycle starts again.

When some protection or procedure is used with low frequency, like restoring data, managing and incident or user recover business functionality using business continuity procedures, I need to perform periodic tests to guarantee that the protection will work as intended when necessary.

My management cycles achieve high levels of maturity when:

• I can forecast the performance of the management cycle.
• The results of testing and verification highlight how fit for purpose are the management cycles.
• I can optimize the use of resources while keeping the same performance and fitness for purpose.

The cybersecurity team is a accountable of monitoring the performance of the protection cycles.

Due to the inherent complexity of IT systems, the prevalence of cloud applications with free tiers, I may lose sight of some assets used by the organization. I concentrate my efforts in protecting the information of higher priority, like Customer and Personal data, and do my best to protect the rest of information.

Besides all the improvements that can be performed on individual assets, it is possible to improve security significantly by create an IT Architecture that makes it easy to meet cybersecurity goals. Ideally protection should be uniform, so equivalent security requirements are solved with the same security solution, and maintenance effort should increase less than linearly as the number of users grows. Some important architecture decisions are:

• Should users be able to work from any device?
• Should users be able to work from any network?
• Should users be able to work from any location?
• What are the sources of truth regarding assets and users?
• What are the third party authorities that can be trusted as sources of truth?
• Are roles designed around what they include or what they exclude from others?
• Do users have visibility of the level of access of their peers?

I document my needs in Request for Proposals and try to get at least 2 or 3 quotes before selecting a provider.

I maintain personal certifications and aim to stay on top of new developments with self-learning and third party training programs.

I instrument collaboration via two periodic meetings:

• Risk and Information Security Committee
• IT Managers.

I have dedicated an open slack channel, where all interested can participate.

A business significant incident happens when I fail to meet a Goal or a Target.

Whereas I strive to prevent cybersecurity incidents, they may occur, and I must prevent the same type of incident from happening again by continuously improving the protection. I document incidents in Incident Reports, including Root Causes and Lessons Learnt

Incident Reports of third parties may also contain lessons applicable to us.

I share my experience if I believe that I learnt lessons that maybe applicable to others and I am not disclosing anything confidential.

ISMS and cybersecurity certifications are useful to enable third parties work with my organization, as they can easily check the degree the organization’s commitment with cybersecurity as I can check theirs depending on the certificates they maintain.

Some management anti-patterns generate work without contributing significantly to the outcome. Being correct is not enough to justify doing something in a certain way, it also has to be useful. To mention just three common anti-patterns:

1. The number of categories to use for any activity should match the number of actions to perform with the items categorized. If you have 4 categories and 3 actions (archive, communicate, fix), you have 1 category too many.
2. Metadata “feels good” as it is correct, but it should not be included unless it necessary to take ulterior decisions. For example “Initial Planned Date” may look good to keep, but unless someone is going to start doing something, stop doing something, or getting a different bonus, perhaps best just forget about keeping this piece of data around.
3. Automation, normally implemented in software, should be introduced when the problem to solve is well understood. Otherwise you may eventually mistake the maintenance of the software solution with the solution of the problem it was designed to solve.

Please add your comments.

As a follow up you can read this: