Situational awareness is just a fancy way of saying "I had better figure out what the heck I've gotten myself into." It encompasses the phase one of the high level strategy that I discussed in my prior post. The first step to building your Information Security program is to understand the current state of the organization and the existing program, even if the term must be used loosely. During this initial phase, observe and ask questions to understand, not to educate. I must stress that it is important to refrain from offering advise, either directly, or veiled in the form of a question too early on. Keep a running list of the tings that need to be fixed. You will want to refer it as you design and implement your controls in phase two of the strategy.
Be forewarned, you are about to undertake a formidable task, and you may run into team members that are less than cooperative as you start poking around. You will need to build trust so that you are not perceived as a threat to their turf or their image. Remember, the team has worked hard to bring the organization to its current state. Even those not driven by ego can be alienated and demotivated if they feel that you are trivializing their contributions, accomplishments, and competence. Frame your discovery and documentation initiatives as a way to help them formally capture and make visible the great work that they are already doing.
Inventory what you have
Data
Meet with teams across the organization to understand the data that the company collects, processes, transmits, and stores. As you do this, begin classifying the data into categories. Though many companies will need to be more fine grained in the long run, the following categories are a good start for most programs. Note that legal and regulatory requirements specific to the business will inform which category some data falls into.
Public - data that is intended to be released publicly
Internal - data that is not intended to be released publicly and would pose a minor impact or risk to the business if disclosed.
Confidential - data that is not intended to be released to publicly and would pose a moderate impact or risk to the business if disclosed.
Restricted - data that is neither intended to be released publicly nor widely accessible internally, and would pose a significant impact or risk to the business if disclosed.
People
Work with the HR team to ensure that there is a complete list of everyone that works for the company. It is not uncommon for organizations to have contractors or other 3rd parties working for them without HR's knowledge. You and the HR team may need to spend time discussing current staffing arrangements with department managers to uncover contractors and consultants that that have access to or possession of company data and equipment.
Hardware
Your quest to inventory all of the company owned hardware will likely take you on a real adventure. The IT team can provide information about most of the computing assets, mobile devices, network equipment, servers, and so-on, but there may still be gaps. The folks that handle facilities, for instance, might have to provide information about cameras, door controls, and alarm systems, if they exist. Work with department managers and the finance team to determine what is being processed on expense reports. This will help you to ferret out things like mobile devices that are outside of the IT departments purview. Keep track of equipment assignments so that you know who each piece of equipment has been issued to. Make sure to collect information about the warranty and support status of each piece of equipment, including the cost of the support contracts.
Systems and Applications
There is a one to many relationship between the physical hardware that a company owns and the number of servers and applications that are hosted on that equipment. The same holds true for cloud infrastructure. Speak with the IT team, especially the front line managers and administrators, to understand what servers and applications are running in your environment, what each does, what data is involved, who owns them, and who has access to them. Take some time to speak with the development team if you have one. It is not uncommon for the development team to have tools and lab environments that they manage themselves, apart from the rest of the organization's IT infrastructure.
Licenses and Subscriptions
In addition to providing information about hardware, systems, and applications, the IT team should also be able to help you compile the list of software licenses and cloud subscriptions that the company has. Keep track of license quantities and license assignments to ensure that the organization is not over provisioned and and that available licenses are being used effectively. Work with department managers and finance team to track down licenses and subscriptions that are submitted through expense reports or have otherwise been procured without the knowledge of the IT team. Don't forget to check with your development teams regarding their tooling and test systems. Just as you did with the physical equipment, make sure to collect information about license terms and renewals, support contracts, and service SLAs.
Document what you do
Network and system diagrams
There should always be up to date network and system diagrams that show the current state of the organization's IT infrastructure. Make sure that the network team creates or updates this documentation to reflect the inventory data that you collected. It should include all relevant information regarding network segmentation, the purpose of each network segment, firewall rules, physical locations of equipment, physical ports used for cabling, and vlan tag assignments.
Policies, Processes, and Procedures
Collect any information that you can gather regarding company policies, processes, and procedures that are already in place and consolidate them into a documentation library if one does not exist already. You will probably have to spend time interviewing team members at many levels across the organization to pull together all of the necessary information. Identify inputs and outputs of the process, who does what, and where different functional teams interface with each other during the process. Document the existing processes in written form and crate accompanying process flow charts and step by step procedure documents and run-books. Include a document control section in each where the process owner is identified, as well as version information, modified date, and approval sign-off are captured. One of the most critical processes that you must document is change control. Identify how changes are made to each of the system. Document the steps in the process, including any relevant stakeholders and approval gates.
Configurations and Standards
Work with the IT team to ensure that the running configuration state of equipment and applications are documented and backed up. If there are hardware and software configuration standards established for items like servers or end-user laptops, ensure that those are documented as well. Capture the baseline hardware specifications for each model that is in use as well as the default operating systems and installed software. The documentation should be of sufficient detail to allow an administrator to replicate the configuration on the device by using the step by step procedure guides and run-books.
Incident Response, Business Continuity, and Disaster Recovery
Speak with executives, department managers, and front-line managers across the organization to gain a good picture of the current state of plans that are in place to deal with the an incident that impacts either the security or the operations of the business. Ask questions about what would happen in various situations that might cause company facilities to become unavailable, infrastructure outages, loss or destruction of data or equipment, sudden unavailability of key personnel, and unauthorized access to systems or data. You want to know how the team plans to respond initially as well as how they will resume normal operations. Take note of critical business processes and who is responsible for executing each of the tasks involved in the plan, including how and when information will be communicated to employees, customers, authorities, or other stakeholders, and timelines for these activities. Don't expect these plans to be well thought out at this stage. Record them as they are so that they can be improved upon as you are designing and implementing your controls.
Compliance and Legal Requirements
It is important to document regulatory and legal compliance requirements that are known to the business. If the organization has any prior audit reports available for SOC, ISO, PCI, or other assessments, review those and consolidate them into your document library. Interview stakeholders across the company to capture and consolidate any available information that you can gather. As you discuss the requirements, also ask about what they company does today to meet that requirement. This is another area where information will likely be incomplete at best. Document the current state in as much detail as possible, and plan to iterate in the next phase.
Don't get the crazy idea that any of this is easy. Inventorying and documenting everything I have outlined here is time consuming, and will take a significant amount of effort and close collaboration with team members in every part of the organization. By the time you finish this phase, you will probably know the inner workings of the company better than anyone else.
In the next post, I will discuss some simple and inexpensive tools that will help you with the inventory and documentation phase on a tight budget. In the mean time, click the "follow" button at the top right corner of the page to follow me on twitter and start a conversation. I would love to hear what you think!
Comments