Integrating Security Mindset with PPT Framework

Continuing my last article, I will make use of what I mentioned regarding the Security Mindset. Please take a looked at my previous story, if you want to know more about Security Concepts.

PPT - People, Process, Technology

PPT is a framework, not only for Security but in modernized business processes. The PPT framework has been around since the early 1960s. Business management expert Harold Leavitt developed his model for creating change in an organization in a paper with the title "Applied Organization Change in Industry."

The three vectors of PPT - People, Process, Technology are all equally important when implementing Security Practices into a System. Putting Security Mindset into play, in this case, could be as simple as thinking of those three vectors separately by putting on one "Hat" (your prime focus) at a time.

I illustrated three "Hats" of thinking in my previous article. Those are the thinking of:

• Security Architect
• Security Engineer
• Security Consultant

I try to use different angles to view the same pillar. The results are thinking the same thing in a totally different way. It is just the start of what you can do. Be familiarized with the concepts are important here so that you can find the focus.

People Pillar

By putting PPT into play, life would be much easier. It is, and will always be, the weakest link among the three pillars. The key to success is to adopt the "Zero-Trust" (or Always verify) model.

1# People - can go wrong.

Think like a Security Engineer can be demanding as the need to illustrate all the probable erroneousness. Even you planned everything flawlessly, but the execution is wrong, everything will go wrong.

Palo Alto Networks presented the concept of "Zero-Trust" clearly:

The Zero Trust model recognizes that trust is a vulnerability. Once on the network, users - including threat actors and malicious insiders - are free to move laterally and access or exfiltrate whatever data they are not limited to. Remember, the point of infiltration of an attack is often not the target location.

Let say we want to build a good Voting System, and it should let people vote in the most efficient way; While for the voting system to be secure, there are a few things that should be considered. Check and Verify could be achieved via AAA (Authentication, Authorization, Accountability).

To verify the People Pillar using AAA:

1. Authentication - How to verify the person's identity?
2. Authorization - How to check if the authenticated person is entitled to vote?
3. Accountability - Can the system report who makes the vote if something is not correct? i.e., Wrong signature/ wrong filling.

People Pillar, when considering it as one part of the system, should investigate all the trust relationships first.

Key Point:

The first thing to handle in People Pillar is the Trust relationship.

2# People - can be a limitation.

Evaluating human resources could be difficult as cybersecurity requires various skillsets across different IT domains. For example, hiring new staff or providing training to the existing personnel could be a big difference in security operations.

Human resources of security personnel, including security guards to technical experts. While lacking can highly increase the response time during incidents, abundance is not always the best solution.

Security Architect thinks about boundaries. Technical staff's skillsets and time requirements to complete a specific task should be analyzed beforehand. Therefore, this kind of thinking should be in the design phase.

Key Point:

Consider People as part of the resources.

Process Pillar

Process Pillar is intangible in nature, unlike People and Technology, which are "real" objects. But it doesn't mean it is not important as the other two. On the other hand, the process should be handled more carefully as the process is not visible. Security Design and Review would be the best actions for this pillar.

1# Process - can be transformed into Procedure.

A procedure is a more detailed and lower-level plan of pre-defined actions. In a Well-defined Security Architecture, there should be different procedures for different processes, e.g., Incident Response Procedure, Disaster Recovery Procedure.

A streamlined process can greatly improve the effectiveness of security operations, especially during an incident. With the improvement of technology, automation is now possible as an integrated part of security solutions and human-intensive tasks in the past.

Key Point:

Create Pre-defined plans and actions under Process Pillar.

2# Process - of Continuous Improvement

The defined, repeatable, and improvable steps you document and train on to perform a function. Processes can drive the effectiveness and success of the security program. They are often one of the critical assets we review when implementing an information security program.

ISO 27001, the international standard of Information Security Management System (ISMS), indicated Quality Assurance (QA) in production environments always talks about the Plan-Do-Check-Act process (PDCA).

Continual improvement is a pivotal aspect of the ISMS in attaining and maintaining the suitability, competence, and effectiveness of the information security related to the organizations' objectives. There is a whole clause about Continual Improvement (10.2) in 27001.

New applications, new technologies, new users… It should be understood that Security landscapes are always advance. Like The Transformers, although Optimus Prime is always there to fight the new enemies, he always has new weapons or a new look.

What you just did flawlessly will be outdated one day. A periodic update and review should be put into consideration at all times. Therefore, an open, creative, and flexible mindset are unnegotiable.

Key Point:

A periodic security update and review for Continuous Improvement.

Technology Pillar

It is the most dependent on Pillar of all. When you realize there are other two Pillars to consider, you will understand why it is not the case buying tools solves everything. Technology can be open-source, self-developed, or purchased from vendors.

1# Technology -Risk/ Vulnerabilities Management

With all the vulnerabilities out there, it is not that obvious for someone to find. It takes a totally different way of thinking. This kind of thinking is not natural for most people. It's also not natural for IT or Engineers. Good engineering practices are to build things that work perfectly.

Security Engineering practices, on the other hand, are to find things that make it fail. Security Engineers are different from IT engineers, at least the good ones, trying to find what can go wrong instead of making it work. All big tech company's Bug Bounty Program relies on this particular mindset.

Finding Vulnerabilities is one thing; fixing it requires a different approach depends on whether you have the source code or not. For self-developed or open-source software, it is easier. For turn-key solutions, it is then a vendor's responsibility to fix or patch the known issue.

Key Point:

Vulnerabilities Finding and Fixing are required for software.

2# Technology - can be a limitation, too.

Similar to human resources, spending on technical means are also under consideration of Security Architect. Whether to use one tool or not depends on the prime goal/security objective.

Understanding the product limitations can also help Architect make better use of the tools and fill the gap by the other two Pillars (People, Process, or both). The limitations can further transform into feature enhancement or new software if significant for the security goal.

Key Point:

Product limitations should be considered and handled by the other two pillars (if possible).

Final words

PPT framework is widely applicable in the technology world. What is missing is integrating this concept and a good security mindset that I tried to illustrate. By doing this, areas of consideration could be more visible in the security landscape.

I hope this explanation can benefit some of you in day-to-day operations in a different part of the security industry. In conclusion, I highlighted the points I mentioned above.

People

• The first thing to handle in People Pillar is the Trust relationship.
• Consider People as part of the resources.

Process

• Create Pre-defined plans and actions under Process Pillar.
• A periodic security update and review for Continuous Improvement.

Technology

• Vulnerabilities Finding and Fixing are required for software.
• Product limitations should be considered and handled by the other two pillars (if possible).

Thank you for reading, happy reading, and learning about the Security Mindset.