It's all about critical processes

Focus on processes, not hardware and software silos.

flow chart process
Credit: Thinkstock

Risk assessments, vulnerability management, and penetration tests are often seen by my students as focused on a server or a set of hardware and software in isolation.  While this might occur in a business trying to test a subset of a system, it is not the best way to protect the business. To fully manage risk, we need to focus on business processes.

The challenge

Business processes run the business.  According to Chris Anderson, writing for bizmanualz, the top 10 core business processes include:

  • Marketing
  • Employee satisfaction [e.g., payroll]
  • Quality management
  • Financial analysis
  • Management operations
  • Sales
  • Product development
  • Product/service delivery
  • Accounting [e.g., accounts receivable and accounts payable]
  • Technology management

In addition to needing attention following a catastrophic business continuity event, these processes must also be the targets of risk assessments. What happens if just one of these processes is interrupted? What is the potential business impact? In addition, we have to assess the likelihood that one or more components of each of these processes will be compromised by an attack or simply fail.

Some of these processes are more important than others. Accounts receivable (the organization’s ability to collect money), product/service delivery, and payroll are the three most important to keep the company operating. This makes the underlying infrastructure and manual tasks for these processes the most critical and the highest priority for risk assessments.

The solution

Once we identify key processes necessary for business operation, we identify all critical infrastructure supporting each process. This likely starts with a process flow diagram, followed by a network diagram.

Figure A depicts a process flow diagram for payroll. I kept this process simple for discussion purposes. This process would likely be a little more complex in an actual organization.

Figure A: Payroll Process Diagram Tom Olzak

Figure A: Payroll Process Diagram

This process diagram helps us see the roles touching the process, what each role does in the process, and provides some idea of data flow. In many cases, we would also develop a data flow diagram to show the data sets passing from role to role or application to application.

We should already have a network diagram showing how the various roles access the information resources necessary to perform their tasks. Network diagrams are an important part of developing security architecture for systems and the enterprise. If they’re missing when you start to assess a process, you might have to regroup and complete the fundamentals.

Figure B shows a simple network diagram. From that network diagram, we can show what network segments and other resources are needed for each step in the process, as shown in Figure C. Once this is completed, we can begin our risk assessment for the process. For brevity, we’ll focus on one step in the process: Approves Employee Entry.

Figure B: Network Diagram Tom Olzak

Figure B: Payroll System Network Diagram

Figure C: Payroll Process with Infrastructure Tom Olzak

Figure C: Payroll Process with Underlying Infrastructure

Please refer to Figure D. The red paths show how managers use the payroll web server (SVR-WEB) for both remote and local access to the information entered by their employees.  (The employees use the web server to enter time worked.) Remote managers have to pass through a Cisco ASA (INT-ASA), are routed from VLAN 50 to VLAN 40 via the core switch (SW-CORE), and access WEB-SVR. Local manager traffic is routed from various end-user VLANs to VLAN 40. Updates are sent periodically by SVR-WEB to the payroll servers (SVR-PR). This requires routing traffic from VLAN 40 to VLAN 10.

Figure D: Annotated Network Diagram Tom Olzak

Figure D: Annotated Network Diagram

When assessing the risk associated with confidentiality, integrity, and availability, we need to assess the following:

  1. Do all devices possess up-to-date patches? Are all devices included in the enterprise patch management process?
  2. Are the servers hardened? If so, what baseline was used and why? Are there services or applications running that don’t have to run?
  3. Are the end-user devices hardened? Are users allowed to install unapproved applications? How are these applications monitored and patched? Do users have unfiltered access to the Internet?
  4. Is user input validated?
  5. Is sensitive information on the servers encrypted?
  6. Is the VLAN traffic controlled with layer 2 and layer 3 access control lists? If so, are all other VLANs other than VLAN 20 (data center ops) blocked from accessing VLAN 10?  If not, why not?  Are trust boundaries crossed?
  7. What happens if SVR-WEB fails? How long before the process can be restored? Do manual processes exist to process payroll ad interim? The same questions must be asked for all other resources involved.
  8. Do remote managers use multi-factor authentication when accessing SVR-WEB?
  9. Are separation of duties and least privilege enforced?
  10. What tools are in place to detect threats?
  11. Is the ASA firewall configured to block all but expected traffic?
  12. How are remote devices checked to ensure compliance with patch and security policies?
  13. Have vulnerability scans been recently performed? If not, perform them. If so, what were the results, and is there a remediation action plan in place.

There are likely additional questions you might ask given your unique operational environment. However, this provides a good start for assessing the payroll process in our example. 

The final word

Again, it’s all about the process. How is our data stored, transmitted, and processed? What happens if something fails? How do we ensure all devices involved in the process are functioning at the appropriate trust levels? Critical processes are important targets for risk and business continuity assessments.

You might notice, too, that these are questions that should have been part of the payroll system design and implementation. But there is always drift. It’s a good idea to keep asking to ensure your change management process hasn’t missed something.

This article is published as part of the IDG Contributor Network. Want to Join?

To comment on this article and other CSO content, visit our Facebook page or our Twitter stream.
Insider: Hacking the elections: myths and realities
Notice to our Readers
We're now using social media to take your comments and feedback. Learn more about this here.