Security Should Start with the Involvement of Top Management

Every organization must not only have a Business Continuity Plan (BCP) involving the assessment of risks and security of their assets and security implementations in place, but also a viable business strategy involving its top-level management adopting a holistic and integrated approach to security, instead of focusing on countering threats alone. Additionally, a cybersecurity approach Defense in Depth is a great strategy for any organization to implement. Learn more about how security should be done in an organization, and why top management plays a crucial role in an org in this article.

What Are Assets?
Assets are precious items that belong to an organization, which a loss thereof could potentially cause disruptions in the organization's ability to perform its functions and deliver services. There are two types of assets: tangible and intangible.

Tangible vs. Intangible Assets
A tangible asset is everything that is physical such as: network equipment, personal computers, servers, or the source code of a product, to name a few. An intangible asset, on the other hand, is an abstract concept which is measurable in some way, and equipped with a precise definition and field of applicability such as the following: a patent, license, trademark, private data, the competence of the personnel, and/or the reputation of the company itself.

Security of Assets
Security has always been used to keep threats outside the network through the use of perimeter defenses such as Firewall, DMZ, Bastion Host, etc., and also the use of Intrusion Detection and Prevention Systems. This was, and still is, the way our assets are protected.

These types of defenses are still absolutely necessary and critical, even if the evolution of today's business models introduces the need to allow connections from the outside world directly to our systems and applications.

This is why it is important to harden and monitor the environments on which our applications reside in the best possible way, and to use a secure approach in developing the applications themselves.

This is because the goal is to have secure applications running in secure environments.

Unfortunately, there is no single method that can successfully protect against every single type of attack. This is where Defense in Depth comes into play.

Defense In Depth

Defense in Depth is a cybersecurity approach in which a series of defense mechanisms are layered in order to protect valuable data and information. If one mechanism fails, there is another to thwart an attack. This layered approach with intentional redundancies increases the security of a system as a whole and addresses many different attack vectors.

Defense in Depth is commonly called the castle approach because it mirrors the layered defenses that a medieval castle would have. Before you can enter a castle, you will find yourself facing the moat, the ramparts, the drawbridge, the towers, the battlements and so on, while archers and other guards will actively defend.

The main security layers are:

Application and Data
Security updates, secure communications, data encryption, authorization management, etc.

Host
Secure configurations, restricting unwanted and insecure services, dynamic whitelisting, etc.

Network
Firewalls, DMZ, IDS/IPS, sandboxing, VPNs, monitoring and alerting, etc.

Physical
Access control, ID cards, fences, CCTV, restricted access areas, etc.

Policy and Procedures
Risk Management, Incident Response, Supply Chain Management, Audit & Assessment, training, etc.

Policy And Procedures

Speaking of policies, standards and procedures, there is a lot of confusion about them. Here are quick descriptions of each to help clarify what each of them are.

Policies
They are formal statements produced and supported by top management. The IT security policy is that document which contains all the provisions, behaviors and organizational measures required of employees and/or company collaborators to combat IT risks.

Standards
They are mandatory actions or rules that support and confirm company policies. They can be internal, like the rules in writing the code, or external, like the PCI DSS or ISO.

Procedures
They are detailed instructions to follow in order to carry out the company policies, and they describe its processes by addressing the following: who does what, when do they do it, and according to what criteria are the policies implemented.

Guidelines
They are recommendations for users when specific standards do not apply. They are designed to simplify certain processes based on best practices.

The Holistic Approach

Most policies and standards should be created by executives for one main reason. The more they get involved in overseeing cybersecurity, the more important it is to make them understand that everything they think they know is probably wrong.

Most of the information reaching these people is focused on countering threats.

But only dealing with threats may not be the right direction. In fact, there is a tendency to equip themselves with a range of individual ad hoc products purchased on the basis of specific stimuli. Often, these solutions do not integrate with other standalone products and are generally not automated, both of which have significant limitations - especially if you want to achieve truly robust cyber security.

The supervision of top management should, on the other hand, lead organizations to adopt a holistic and integrated approach to security, primarily focused on business strategy, on the essential processes to achieve it, and on the main primary risks based on assets.

Once these elements which are crucial to the success of the company have been identified, it is possible to identify the internal and external threats that could put them at risk. This approach allows an organization to direct its cyber protection resources, inevitably finite and limited, to where they are needed most, instead of dividing the investments over the infinite number of possible security measures.

Risk Management

How can we evaluate and prevent the so-called primary risks? There is precisely a process called Risk Management.

Risk Management is the process by which risk is measured or estimated, and strategies are subsequently developed to govern it.

The Risk Analysis first begins with the identification of the assets that need to be protected. Next, it evaluates possible threats and potential damage in terms of probability of occurrence, known as severity.

Based on the risk estimate, a decision can be made on what security countermeasures will be adopted, thus creating a Risk Plan.

Risk Calculation

Calculating risk estimation is a precise technique, which is based on three simple concepts:

Single Loss Expectancy (SLE)
It is the product of the asset value normally expressed in money, and the exposure factor usually expressed as a percentage. The value found is the estimate of the potential loss.

SLE = Asset Value * Exposure factor = $ * %

Annual Rate of Occurrence (ARO)
It is the sum of the number of accidents due to a specific threat that occurs in a year. It has a statistical value in determining a potential future risk.

ARO = Sum of accidents in the last 12 months

Annual Loss Expectancy (ALE)
It is given by the product of the SLE and ARO, and it represents the measure of expected losses in a year.

ALE = SLE * ARO

It should be noted that risk management when applied to software is not that easy as the determination of software assets may be subjective, and the statistics on violations in this area are limited.

Risk Countermeasures

After evaluating a risk, what should we do?

Take for example the scope of PCI DSS. This tells us that we must protect Cardholder Data (CHD) avoiding storing Sensitive Authentication Data (SAD). Here the risk is high, and we are forced to manage it.

There are cases in which we are not forced to deal with specific regulations, but some risks that threaten our assets have nevertheless been identified. Management has several options for deciding how to manage risk:

Ignore
Ignoring the risk. This is usually chosen in cases where both the likelihood of it happening and the harm it can cause is low.

Avoid
Avoiding risk, for example, by excluding a certain business logic permanently or finding safer alternative solutions.

Mitigate
Mitigate the risk by implementing specific controls and accepting the residual risk, that is, the level of risk that remains after the measures were implemented by management, to reduce the impact and probability of occurrence of an event.

Transfer
Transfer the risk, for example, by entering into a contract that clearly defines that the risk of the materialization of threats is the responsibility of the third party.

Risk Calculation Example

The manager says Business Continuity is a key factor for the company. It is an intangible asset valued as 7/10 of the overall budget of the project, or in our case $50,000.

The exposure factor to the loss of continuity of services is 3%, which means that if the service is interrupted for a sufficiently critical time, 3 out of 100 customers will permanently abandon the service.

In the previous year, there has been 16 service interruptions mainly due to an incorrect database design that causes a Denial of Service.

We therefore have the value of our asset, in this case Business Continuity, of $35,000 (7/10 of 50,000). This gives us an exposure factor of 3% multiplied by 16 outages in the last year with the following values:

SLE = Asset Value * Exposure Factor = 35,000 * 0.03 = $ 1,050

ARO = Sum of accidents in the last year = 16

ALE = SLE * ARO = 1,050 * 16 = $ 16,800

The expected loss during the year is 33.6% of the project's budget!

Although the budget is high, we have a high probability that the threat will materialize, and a considerable amount of monetary loss will result as a consequence. The problem was located in the incorrect design of the database of our application, such as stored procedures that are slow in processing and blocking the system, which was designed, hardened and maintained with extreme care.

The Application Could Be The Weakest Link

Despite having a totally safe and performing environment, the application could be the weakest link in the entire chain.

A chain is only as strong as its weakest link

The previous example talked about "only" a Denial of Service, but a more critical security bug could endanger the entire company.

If, instead of having slow processing stored procedures, we had had an SQL Injection, the consequences would have been worse.

For example, in a web application, the frontend communicates with the backend via the HTTP(S) protocol. Each request is like a closed envelope that passes through all perimeter defense systems and is opened directly by our application. Defense systems at the network and operating system level do not provide vulnerability checks such as SQL Injection, which are exclusively specific to the application itself.

The example on the web application is not a coincidence. Web attacks have increased dramatically in recent years, thanks also to the fact that they can be carried out by people who are not properly skilled.

Think of a native application such as Android, iOS or Windows, which requires knowledge of the operating system, development languages, and reverse engineering. Many web attacks instead are performed with automatic tools such as Burp Suite using pre-made payloads, in a context where it is not necessary to have complete knowledge of what is happening.

It is increasingly necessary to implement security already in the design and development phase of the applications.

Obstacles In The Implementation Of Security

There are some obstacles to overcome when trying to introduce the concept of security through the entire development life cycle, especially if it is a process that already exists in the company.

Among these are the Iron Triangle, Security as an afterthought and Security versus Usability.

Iron Triangle

The development of an application is fundamentally influenced by three factors: Time (the time available), Scope (the objectives), and Cost (the budget). Security requirements are typically seen as something extra, and often the costs and time available for the project do not allow them to be implemented.

Security As An Afterthought

Security is implemented in the final phase of the project, most often in the production environment. If there are any problems, solving them involves a significant waste of time and budget, often forcing developers to work around them.

Security Versus Usability

Most of the time, security decreases the usability level of the application arousing discontent - both among the developers who have to implement it - and among the end users who find themselves having to perform several steps (sometimes even complicated ones, in order to use the services).

However, even if we have to fight with our managers and C-levels, we have a duty to design and implement the software conscientiously, and have a sensitivity towards issues related to its security.

Another reason is, we will have to solve all the problems that come out anyway.