Overview
- To maintain an effective cybersecurity posture, the Chief Information Security Officer (CISO) should maintain a number of cybersecurity operational processes.
- As suggested by the graphic, this appendix describes a set of such processes and their supporting information systems.
- While this list is not all-inclusive, it includes important processes for effective cybersecurity.
- These processes are usually operated from within enterprise functional areas.
- Processes cross over organizational and technological boundaries so they are somewhat manual and procedural.
Topics
- 1.Policies and Policy Exception Management
- 2.Project and Change Security Reviews
- 3.Risk Management
- 4.Control Management
- 5.Auditing and Deficiency Tracking
- 6.Asset Inventory and Audit
- 7.Change Control
- 8.Configuration Management Database Re-certification
- 9.Supplier Reviews and Risk Assessments
- 10.Cyberintrusion Response
- 11.All-Hazards Emergency Preparedness Exercises
- 12.Vulnerability Scanning, Tracking, and Management
- 13.Patch Management and Deployment
- 14.Security Monitoring
- 15.Password and Key Management
- 16.Account and Access Periodic Re-certification
- 17.Privileged Account Activity Audit
Policies and Policy Exception Management
- This process main tains enterprise policies and exceptions to those policies.
- Enterprises may be good at establishing and maintaining processes, but managing exceptions to policies tends to be more problematic.
- Enterprises need to ensure policy exceptions are formally approved and re-certified.
- Security leadership needs to observe policy exceptions carefully so the “exception does not become the rule.”
- 1.Propose Policy: Security team proposes a policy be created.
- 2.Review Policy: Business leadership, strategy/architecture, engineering, and operations review the policy to ensure it is reasonable and supports the business.
- 3.Approve Policy: Business leadership approves the policy after it has been reviewed and revised, as needed, to balance risk with business needs.
- 4.Establish Policy: Security team integrates policy with rest of the security policies and established methods for monitoring and enforcing policy. Policies should be periodically reviewed and updated. This sub-process is not shown i n the graphic.
- 5.Request Exceptions: Strategy/architecture, engineering, and operations teams may find they need exceptions to the policy.
- 6.Analyze Risk: When exceptions are requested, security team analyzes the risk associated with the exceptions and reports that risk to business leadership.
- 7.Accept Risk: Business leadership balances the business value with the associated risk to make a business decision on approving the exception and accepting the associated risk.
- 8.Track Exceptions: Security team tracks approved exceptions and ensures they are periodically re-certified.
- 9.Re-certify Exceptions: Requesters are required to periodically re-certify their exceptions to ensure the exception need still exists and the risk is still acceptable.
Project and Change Security Reviews
- This process involves cyber security in enterprise projects and changes.
- Process ensures, in part, that IT systems are designed and deployed with cybersecurity capabilities “baked in” to the best extent possible and that they are practical.
- Process should be integrated into the larger system development life cycle process and can be part of the management gates.
- 1.Initiate Project: In response to a business need, the business leadership initiates a project for a new system or an existing system change.
- 2.Architect Solution: In context of the overall enterprise, the strategy and architecture team architects the solution, in part, by identifying technologies and standards that comprise the solution. The team factors security policies and standards into the solution.
- 3.Develop System: Next, the engineering team develops the system or change, taking the architecture and security standards into consideration. The engineering team designs the system by balancing performance, security, and cost requirements, as well as other constraints.
- 4.Identify Vulnerabilities: During the system design process, security reviews the proposed design and identifies vulnerabilities. They are defined in terms of threats and business consequences that result in confidentiality, in tegrity, or availability (CIA) losses.
- 5.Remediate Vulnerabilities: As vulnerabilities are identified, the system is engineered to reduce the potential threats and negative business consequences. Sometimes, mitigating the vulnerabilities may not make business sense.
- 6.Approve Operation: Business leadership considers the identified vulnerabilities and corresponding business risks. If the risks are too great, engineering needs to modify the system design to acceptable risk levels. Once the business leadership accepts the risk, they grant and document the approval to operate (ATO).
- 7.Track Risk: Security team then documents the residual risks in the enterprise risk database. Documentation includes threat scenarios and associated business impacts on CIA.
- 8.Transition to Operations: Once the system is approved to operate and residual risks are accou nted for, the system can be transitioned to operations.
Risk Management
- This process involves identifyi ng, analyzing, and tracking risks and their associated mitigating controls.
- It is important the CISO tracks risks in terms of their business impact, not their technology impact; risks should be technology-agnostic.
- Technology factors into the risk process as vulnerabilities are identified and exploited by attackers; associated business risks can increase and possibly require additional mitigations.
- 1.Identify Risk: Security team starts the process by identifying risk. In the event of a risk re-certification or review, this activity may involve taking an existing risk and initiatin g the process to review it.
- 2.Analyze Risk: Next, all departments analyze risk from their perspectives. The departments evaluate the importance/consequences of the risk and potential mitigations.
- 3.Design Controls: Security team works with engineering to design controls to mitigate the risk, either by reducing its probability or reducing its impact. In some instances, the best business decision may be to accept the risk as is without mitigation.
- 4.Approve Risk Plan: Business leadership reviews the risk and the planned mitigation measures to ensure the risk plan balances performance, security, and cost to serve the needs of the business.
- 5.Implement Controls: Once the risk plan is approved, engineering implements the controls and prepares them for production. Engineering is involved in the control design to ensure the planned controls are actually achievable.
- 6.Operate Controls: After the controls are designed and implemented, operations takes responsibility for the day-to-day activities.
- 7.Track Risk: Finally, the security team tracks the risk, along with its associated mitigating co ntrols, via the enterprise risks database.
Control Management
- This process involves identifying a nd tracking enterprise security controls.
- Tracking controls are helpful because they allow management to track how security resources are being allocated to mitigate risks while preserving business value.
- A good control identifies the risk it mitigates, whether it is reducing the probability or the reducing the impact of the risk, and who is doing what to deliver mitigation.
- It is helpful to tie this process to incident management process so controls are developed to mitigate risks related to real-world cyberincidents.
- 1.Identify Controls: Security team identifies the controls to be considered, which either come from the risk management process (in other words, identifi es new controls) or a review of existing controls.
- 2.Evaluate Controls: Next, security, strategy and architecture, engineering, and operations consider each of the controls from their perspectives. Generally, business leadership does not need to be involved.
- 3.Revise Controls: Security team works with engineering to create, update, or modify the controls based on the results of the evaluation process.
- 4.Approve Controls: Business leadership reviews the revised controls in light of the risk and potential business impact to ensure performance, security, and cost are appropriately balanced to serve the needs of the business.
- 5.Implement Controls: Once the business leadership approves the revised controls, engineering implements the controls and prepares them for production. Engineering is involved in the control design to ensure the planned controls are actually achievable.
- 6.Operate Controls: After the controls are designed and implemented, operations takes responsibility for the day-to-day activities.
- 7.Investigate Incide nts: During operation, the controls will generate security incidents that will require security to conduct an investigation.
Auditing and Deficiency Tracking
- This process involves p eriodically reviewing security controls to identify deficiencies when controls are not designed properly, or are not working as designed.
- Audits are essential to maintaining controls.
- Audit types include self-audit, internal audit, and external audit.
- 1.Identify Controls: Security team identifies the controls to be audited. Seldom will a single audit consider all controls; most likely an audit is a subset of all controls. Note that for internal and external audits, the process is directed by a department outside of IT, but it should still be facilitated through the security office.
- 2.Support Audit: Engineering and operations personnel support the audit by answering questions on the design and operation of the control.
- 3.Identify Deficiencies: During the course of the audit, security documents and tracks deficiencies.
- 4.Redesign Controls: In response to deficiencies, engineering may have to redesign or modify the controls.
- 5.Update Procedures: In response to deficiencies and control redesign, operations may h ave to update their procedures for operating the controls or improve the execution of the procedures that are already in place.
- 6.Track Remediation: Security tracks the changes to the controls or their operation and works with the audit team to determine if the changes constitute adequate remediation of the deficiency. Note that not all deficiencies are resolved successfully; sometimes it may make better business sense to simply accept the deficiency.
- 7.Map Results to External Audits: For audits that are performed against an external standard such as NIST, PCI, or HIPAA, security maps the audit results from the internal controls to the requirements of the external framework.
- 8.Receive Results: Senior leadership receives the audit results. In situations where deficiencies are accepted and not resolved, senior leadership weights in on the business sense of such decisions.
Asset Inventory and Audit
- This process involv es tracking / auditing IT assets to ensure the enterprise assets actually present match the assets believed to be present.
- A wide range of assets are tacked, including physical computers and technology equipment, licensed software, and key and security measures.
- Finance generally requires capitalized assets to be tracked for depreciation purpose; for IT security purposes, other assets are tracked as well.
- Frequency of audits is dependent, in part, on the asset type, value, and asset security.
- 1.Track Assets: Operations tracks assets throughout their life cycle, from acquisition to disposal.
- 2.Request Audit: Security initiates the audit process by requesting it. The process is often on a regular schedule (for example, annually) or as a rolling audit where partial inventories are done monthly or quarterly.
- 3.Account for Assets: Unde r security’s supervision, operations audits assess by identifying discrepancies.
- 4.Investigate Discrepancies: When discrepancies are found, security tracks them and attempts to determine if the reasons for the discrepancies are a process problem or an execution problem.
- 5.Remediate Discrepancies: When discrepancies are investigated, operations remediates the discrepancies so the actual inventory matches the asset database content.
- 6.Conclude Audits: Security concludes the audit by compiling the results of what was audited, what discrepancies were found, and how the discrepancies are remediated. The report includes valuing the cost of the discrepancies. Cost values are important in making business decisions in response to the audit.
- 7.Receive Results: Senior leadership receives the audit results and makes business decisions, which might include changing processes, investing in asset management t echnology, or disciplining employees for not following procedures.
Change Control
- This process involves mana ging changes to the IT environment.
- Control Management is of interest to security.
- Changes are carefully planned to ensure they do not introduce unplanned vulnerabilities to IT environment.
- Changes that occur without authorization or approval can be signs of deliberate attack.
- Change control process helps ensure smooth IT operations.
- 1.Initiate Changes: Engineering initiates this process. Ideally, changes are documented and tracked through a change management system (not shown).
- 2.Review Changes: Security should have an opportunity to review changes prior to their approval.
- 3.Approve Changes: By consid ering the business value of the proposed change in regard to operations, security risk, and cost, business leadership approves all changes prior to implementation and execution.
- 4.Modify Configurations: Once business approves the change, operations modifies the configuration in accordance with established procedures.
- 5.Update Databases: After operations completes the changes (or in conjunction with executing the changes), operations updates asset and configuration management databases to document the change.
- 6.Audit Changes: As part of the change completion process, security audits the change to ensure what was actually changed matches the documentation.
- 7.Identify Discrepancies: Audit may identify discrepancies where what was changed does not match the documentation. These discrepancies are particularly common when automated systems are used to constantly scan for unauthorized changes. Discovered discrepancies should be treated as security incidents for investigations.
- 8.Investigate Discrepancies: When discrepancies are identified, engineering and operations work with security to investigate the discrepancies and de termine what happened.
Configuration Management Database Re-Certification
- This process invo lves periodically auditing system configurations against the configuration management database to verify that system configurations match the database.
- Unplanned changes, debugging and troubleshooting, and attacker activity can result in configuration discrepancies that need to be resolved periodically.
- Security should review the changes to ensure that discrepancies are not the result of attacker activity.
- 1.Track Configurations: Operations tracks configurations as a normal course of business and formal change control.
- 2.Request Re-certification: Security initiates the re-certification process, which is done on a routine schedule (for example, quarterly or annually), in response to an identified discrepancy, or to support other audit activities.
- 3.Identify Discrepancies: Operations reviews system configurations compared to the database and identifies discrepancies where the configurations do not match the database.
- 4.Review Discrepancies : Engineering and security review discrepancies to determine if the discrepancies are evidence of malicious activity or represent an engineering or security risk.
- 5.Reconcile Discrepancies: Operations reconciles the discrepancies with what is in operation (that is, configuration management database). This reconciliation may involve either updating the database or updating the configuration so they both match. Obviously, if the configuration is to be changed, proper change control procedures must be followed.
- 6.Conclude Re-certification: After all discrepancies have been reviewed, security concludes the re-certification. This activity may include tracking the re-certification results to identify systemic and process problems over time.
Supplier Reviews and Risk Assessments
- This process reviews t he enterprise supply chain to ensure it is consistent with the overall architecture and does not pose undue risk to enterprise cybersecurity.
- Supplier risks include supplier location, foreign government or competitor influences, supplier vulnerabilities, regulatory compliance, and supplier access to enterprise IT systems.
- Suppliers must be periodically reviewed and their security assessments updated in light of threats.
- 1.Identify Supplier: Architecture team identifies suppliers for consideration. Strategy and architecture have visibility on all major enterprise suppliers to ensure suppliers and their technologies are consistent with the overall enterprise architecture.
- 2.Identify Risks: Security team evaluates the supplier risk, considering how the supplier interacts with the enterprise. Do suppliers have access to enterprise ne tworks, or supply hardware, software, or services? Identifying risks considers a wide range of potential threat scenarios related to CIA.
- 3.Analyze Risks: Business leadership, strategy / architecture, engineering, and operations analyze the supplier risk to understand the potential impact should it manifest itself.
- 4.Design Mitigations: Engineering collaborates with security (not shown in the graphic) to design mitigations to reduce the probability or the impact of those supplier risks, if possible and warranted.
- 5.Approve Supplier: Business leadership formally approves the supplier risk mitigations by considering the business impact, risks, mitigations, and costs involved.
- 6.Add to Architecture: Strategy and architecture add approved suppliers, along with any risk assessment caveats, to the enterprise architecture.
- 7.Track Risks: S ecurity tracks the risks associated with the approved suppliers.
Cyberintrusion Response
- This process is used to inv estigate identified incidents, contain the breach or instruction, and restore normal business operations.
- The process is central to a modern, responsive cyberdefense, and it is led by the security CyberIncident Response Team (CIRT).
- CIRT works with engineering and operations throughout the process.
- 1.Identify Incident: Operation team identifies a security incident has occurred. Identification includes reviewing and investigating alerts from monitoring systems and conducting searches for suspected attacker activities based on known patterns.
- 2.Investigate Incident: Secu rity investigates and tracks the identified incident and identifies the tools, techniques, and procedures used in the attack. Scope often expands as more hosts, accounts, and networks are identified as being involved.
- 3.Collet Evidence: Security collects evidence that may be used by law enforcement, but may also be of interest to auditors and regulators.
- 4.Receive Initial Reports: Security reports the status of the incident to business management. Status covers the business impact in terms of breaches of CIA, as well as the anticipated business impact due to the remediation. Business leadership, along with security, updates the enterprise risks to document how enterprise was exploited.
- 5.Contain Incident: Operations moves forward to contain the incident to stop the attackers from being able to operate in the enterprise environment and limit further damage.
- 6.Repair Vulnerabilities: Vulnerabilities exploited by the attackers are identified and remediated as well as possible. Engineering tracks vulnerabilities that cannot be repaired immediately and considers alternative mitigating controls.
- 7.Remediate Compromises: Operations remediates and restores the attacked assets (fo r example, computers, user accounts, and networks) back to normal operation.
- 8.Validate Remediation: Security validates the remediation activities to ensure the incident has been contained, vulnerabilities have been repaired, and compromised assets remediated.
- 9.Receive Final Report: IT department fully documents the incident and covers the business i mpact, explains what the incident means going forward, and recommends actions to strengthen defenses.
All-Hazards Emergency Preparedness Exercises
- IT department uses this process to develop and exercise procedures for emergency preparedness and disaster recovery (DR).
- Procedures should be generalized for all types of emergency situations (all-hazards) and should be usable for a variety of crises.
- Procedures should include manual workarounds, failover of applications or business processes to alternate sites or infrastructures, and restoration of data and applications from backups.
- For information systems, availability DR should be considered in terms of recovery point objectives (RPO) and recovery time objectives (RTO).
- 1.Initiate Disaster Recovery (DR) Planning: Security team ensures DR plans are maintained and periodically updated. Team initiates exercise process periodically (for example, annually).
- 2.Develop Procedures: Engineering develops or updates the DR procedures that cover a wide range of possible failure scenarios. Particular attention is paid to personnel factors to ensure success is not dependent on any one person.
- 3.Coordinate with Ven dors: IT DR system procedures are highly dependent on underlying technology capabilities. Engineering and operations develop procedures in close coordination with vendors.
- 4.Coordinate Exercise: When draft procedures are ready, security team coordinates an exercise to test and practice the procedures. The scale of the exercise is based, in part, on cost, schedule, and business impact factors.
- 5.Exercise DR Procedures: Operations teams lead the practice of the DR procedures, as documented in the plans. Exercise can be a simple procedures walkthrough, a tabletop mock drill, or a full failover.
- 6.Revise Procedures: Based on exercise results, if needed, engineering leads the revision of the DR procedures and plans.
- 7.Evaluate Results: Security compiles the exercise results to be reported to business leadership.
- 8.Brief Leadership: Security briefs business leadership on exercise results, highlighting the business risks posed by disaster scenarios and the parameters for recovery point objectives (RPO) and recovery time objectiv es (RTO).
Vulnerability Scanning, Tracking, and Management
- This process is relativel y straightforward and involves using tools to scan for vulnerabilities in network-connected systems.
- Vulnerabilities allow attackers to disable systems, disrupt their operation, modify data, or in the worst case take full control of those systems to access the enterprise and its data.
- Not all vulnerabilities can be patched or remediated.
- Security team considers overall enterprise risks to understand how unresolved vulnerabilities potentially impact the CIA of critical data.
- 1.Scan for Vulnerabilities: Security team initiates vulnerability scans. Traditionally, operations performs this activity, but security team ensures scanning is being conducted on a regular basis. Scanning is done using automated tools, although manual procedures can be followed as well.
- 2.Track Vulnerabilities: Security tracks identified vulnerabilities for remediation. Some vulnerabilities may need to be accepted; in those cases, mitigating controls should be considered.
- 3.Patch Vulnerabilities: For many vulnerabilities, the fix is as simple as installing a patch or performing a re-configuration.
- 4.Mitigate Vulnerabilities: Engineering mitigates vulnerabilities that cannot be simply patched or addressed. Mitigation may be through preventive controls that make the vulnerability harder to exploit or detective controls to catch exploits when they occur.
- 5.Verify Mitigation: When engineering performs mitigation, the security team is consulted to verify the mitigation will be effective and perform as desired.
- 6.Identify Risks: Security considers the business impacts of the vulnerabilities, their remediation, and any mitigation performed. It then uses that information to update the list of enterprise risks, as necessary.
Patch Management and Deployment
- This process deploy s patches to operational systems to address vulnerabilities, operational problems, or simple routine software maintenance.
- It is critical for enterprises to have a patch management and deployment process that is tightly integrated into IT operations and maintenance.
- This process needs to allow for the occasional deployment of unscheduled, emergency patches.
- 1.Identify Vulnerability, Operational Need, or Routine Software Update: Security identifies the need for a patch: security vulnerability, an operational problem, or routine software patches from vendor. First, two patch needs may necessitate non-routine, “emergency” patching.
- 2.Obtain and Test Patches: Operations obtains the software patches and ensures their legitimacy and compatibility with the systems to be patched.
- 3.Determine Patch Pla n: For emergency patches, engineering reviews the patches to ensure adequate testing is performed and the operational or security risk warrants deploying the patch outside of the routine patching process. The patch plan includes back-out and contingency procedures.
- 4.Approve Emergency Patch: For emergency patches, business leadership makes the final decision to patch outside of normal procedures, evaluating the overall business risk.
- 5.Deploy Production Patches: Upon approval, operations proceeds with the patching either using normal operating procedures and maintenance windows, or using the emergency patch plan prepared by engineering.
- 6.Verify Operational Fix: For emergency patches in particular, engineering reviews the system post-patching to verify the system is operating as expected.
- 7.Verify Security Fix: For security patches, security reviews the system post-patching to verify the security vulnerabilities of concern have been adequately add ressed.
Security Monitoring
- This process is one of the most fundamental enterprise security processes and is a “must-have” for countering modern threats.
- Process involves designing alerts triggered by likely adversary activity and then using those alerts to identify incidents in the environment.
- Process should be ongoing, not only to monitor systems and identify incidents, but also to continually refine the alerts to reduce false positives and search for new indicators of compromise (IOC).
- 1.Adversary Intelligence: Security needs to understand the adversary threats that should be detected. Threats are considered in terms of the assets they affect and the business consequences should the threats occur. For deliberate attackers, the attackers’ tools, techniques, and procedures are considered, if known.
- 2.Indicators of Compromise (IOC): From the threat scenarios, security can determine IOC that would indicate attacker activity or events. These indicators may be as simple as an anti-virus alert, or may be sophisticated patterns t hat can be identified with a correlating log system. These indicators may be automated indicators obtained from an external service or internally deployed analytics technologies.
- 3.Design Alerts: Based on IOC, engineering designs alerts to be triggered when those indicators are present. The alerts are designed to have a high fidelity, while also to minimize the numbers of “false positives.”
- 4.Operate Monitoring: Alerts are then passed on to IT operations that uses the monitoring capability to detect the alerts when they occur. During daily operations, the alerts are periodically tested to ensure they are functioning properly.
- 5.Identify Incidents: As monitoring detects alerts, security evaluates these alerts to identify incidents for investigation. A single incident may come from multiple alerts, just as a single alert may be related to multiple incidents. The difference here is that incidents are manually created, while alerts are usually automated.
- 6.Investigate Incidents: Operations hands off detected incidents to the incident response team, which then follows the cyberintrusion response process to investigate and resolve the incident.
- 7.Identify False Positives: Some incidents may turn out to be false positives after investigation. Too many false positives may prompt the IT department to modify the alerts to reduce the amount of unnecessary alerting and investi gation.
Password and Key Management
- This process is used to man age the life cycle of cryptographic keys from creation to destruction.
- It is important to remember that passwords are essentially keys that are easy to write down.
- Keys have life cycles driven by factors such as their cryptographic strength, usage patterns, probability of compromise, and potential attack vectors.
- Strong cryptographic keys (and passwords) can still be compromised.
- Detecting com promised keys can be extremely difficult, if not impossible.
- 1.Create New Key: Engineering or operations creates a new key or password. Note this process primarily refers to organizational keys or passwords, although personal accounts can be managed this way if there is a compelling business need.
- 2.Store Key in Vault: Once the key is created, it is archived for protection. Key can be retrieved and changed when necessary.
- 3.Request Key Rotation: Keys must be rotated in accordance with security policy. This activity should be audited on a periodic basis.
- 4.Update Keys: As keys are rot ated or otherwise updated, operations updates the key vault to reflect the new key material or password value.
- 5.Request Re-certification: Security should periodically request re-certification of keys to ensure the keys are still needed and the people responsible for the keys have access to the keys.
- 6.Re-certify Keys: Key re-certification ensures the keys are still needed, people responsible for the keys have access to the keys, and the corresponding information is up-to-date.
- 7.Retire Keys: Engineering retires keys at the end of the life cycle or when the system using them is retired.
Account and Access Periodic Re-certification
- This process is used to m anage the life cycle of enterprise accounts and permissions.
- Generally, accounts and accesses are granted when they are needed, so provisioning seldom presents a problem.
- What is a problem is de-provisioning, where accounts and accesses that are no longer needed are released in a timely fashion.
- De-provisioning is primarily a function of identity and access management technologies, which are critically important in large organizations.
- Without these technologies, th e same results can be achieved via periodic re-certification / audit of accounts and access to ensure they are de-provisioned, and to check that the most critical privileges are not abused.
- 1.Design Systems: Accounts and accesses generally stem from systems that utilize them and the people who need access to those systems. Engineering designs and deploys systems along with associated accounts and access permissions.
- 2.Create Accounts: Once there are systems that require accounts, operations creates account for access to those systems.
- 3.Assign Permissions: Opera tions assigns account permissions for enterprise systems to allow people access. There are three general levels of system permissions.
- Administrators—Ability to install and configure the computer, database, or application
- Operators—Ability to manipulate the data, but cannot change application
- Users—Have unprivileged access to the application and data
- 4.Request Re-certification: Security ensures accounts and permissions are periodically re-certified so unused account and permissions can be removed. The more decentralized the enterprise is, the harder re-certification process will be.
- 5.Re-certify Accounts and Permissions: Operations conducts the re-certifications and keeps tracks of accounts and permissions so they can be re-certified in a timely manner.
- 6.Retire Accounts: Op erations de-provisions accounts and accesses that are not longer needed.
Privileged Account Activity Audit
- This process is used to au dit the actions performed by the enterprise’s most privileged accounts.
- Accounts should be selected using a risk-based method .
- Focus on accounts for which there are few safeguards
- Focus where compromise of the account could result in the compromise of the entire enterprise or a signification portion
- Robust audit trail of all activities using these accounts is needed.
- If accounts are compromised, the audit trail cannot be simply “turned off” without being detected .
- 1.Perform Systems Administration: Operations performs systems administration activities that generate, in part,
- an audit trail of all activities using the privileged accounts; and
- alerts for security to review certain activities.
- 2.Review Audit Logs: Security team reviews the activity audit logs, which may reference change records and the configuration management database. Note it is helpful for operations to also get the audit logs so they can perform their own review.
- 3.Investigate Discrepancie s: Security investigates activities that are suspicious or outside of normal patterns. Note that, while it is helpful to enable operations staff to conduct their own review and investigation to properly mitigate insider threats, it is necessary to have a separate team also performing these investigations.
- 4.Support Investigations: Operations needs to support the investigation process. While they are instrumental in supporting these investigations, it is important to ensure they are not self-auditing, either.
- 5.Identify Incidents: Investigations that turn up discrepancies generate incidents for follow-up by the CyberIncident R esponse Team (CIRT), through the cyberintrusion response process.