Create a Virtual CISO Using AI in Google’s NotebookLM
A Chief Information Security Officer (CISO) is expected to know and do much. A CISO must know cybersecurity laws, regulations, and industry best practices. In addition, a CISO is also expected to understand how to implement technical controls to protect the organization’s data and know how to respond to a cybersecurity incident. With this knowledge, a CISO can answer questions like:
What should be in an Incident Response Plan?
What should I do if I receive a phishing email?
What are the PCI requirements for firewall configurations?
How do I see which executable files were run on a Windows computer?
What is the definition of personal information according to Hawaii law?
What is the best practice for managing software vulnerabilities?
A CISO's knowledge and capability are not just theoretical but honed through practical experience and the application of published documents, guidance, and best practices. These practical tools, often the culmination of extensive research and experience, equip a CISO to navigate the complex world of cybersecurity effectively and authoritatively.
Over the past two decades, the volume of research and the number of cybersecurity-related publications have consistently increased. A Google Trends query on “cybersecurity” from 2004 to the present day reveals a significant and continuous growth in interest in this crucial topic.
CISOs enjoy a high average salary because they possess this expertise, but the turnover rate due to “burnout” and other factors makes it difficult for an organization to manage and maintain a stable information security program and manage cybersecurity risk. If there is a new CISO every two years, those transitions introduce vulnerabilities themselves. An organization requires a reliable and consistent source of cybersecurity expertise that can be consulted at all times by all levels of an organization.
AI to the Rescue
The amount of research at all levels of government, academia, and commercial industries makes “cybersecurity” and “information security” a perfect candidate for the application of generative artificial intelligence (AI), specifically retrieval-augmented generation. Those familiar with generative AI tools like ChatGPT may immediately suggest sending the questions enumerated above to ChatGPT for answers. This is one approach that will provide some decent guidance. However, with ChatGPT, there is a possibility that the output will be inaccurate. Below is a screenshot from their Terms of use dated January 31, 2024:
Generative AI is inherently probabilistic, which means it is not perfectly accurate. Therefore, how can you use it while reducing the probability of generating inaccurate information? That is where the retrieval-augmented generation (RAG) process comes in. The RAG model enhances the quality and relevance of the text generated by a pre-trained large language model (LLM) by using pre-processed authoritative information to influence the output returned by the LLM. This increases the probability that the output is based on the authoritative information introduced to the LLM, and not just on the LLMs pre-trained probabilities. Practically speaking, with RAG, the output more likely reflects the facts and intent of the authoritative information. Therefore, for our use case, we want to create a generative AI service that bases its responses on the authoritative information and cyber security documents we select.
Building a CISO
The first thing we need to do is identify the authoritative documents to ground our Virtual CISO AI. To cover a broad spectrum of capabilities, I have decided on the following documents:
NIST Cybersecurity Framework 2.0
NIST Guide to Cyber Threat Information Sharing (NIST 800-150)
NIST Incident Handling Guide (NIST 800-61r2)
Incident Response Policy Template from the Center for Internet Security
Federal Government Cybersecurity Incident and Vulnerability Response Playbooks
U.S. Department of Defense Cyber Incident Handling Program (CJCSM 6510.01B)
11 Strategies of a World-Class Cybersecurity Operations Center by MITRE
Payment Card Industry Data Security Standard (PCI DSS v4.0)
Hawaii Revised Statutes Chapter 487N, Security Breach of Personal Information
Microsoft Windows 11 Enterprise Benchmark v1.0 from the Center for Internet Security (secure configuration guide)
This is a well-rounded set of resources that advise on cybersecurity risk management, incident handling, detailed security configurations for a Windows workstation, and Hawaii law. You would like to include more. However, this is a good set of authoritative resources to demonstrate NotebookLM, and the benefits of AI implemented as a RAG model.
Configuring NotebookLM
Access NotebookLM by going to https://notebooklm.google.com. Click on the “New Notebook” button to start a new notebook.
At the interface's left is the list of authoritative sources for this notebook. To the right will be the notes derived from chat queries or custom notes you create as you explore your sources. At the bottom right is a panel and input box for your chat queries. Responses are displayed above once you begin a conversation.
The first thing you need to do is to upload sources. There are a some limitations that you need to be aware of as of May 28, 2024:
A single source is limited to 200,000 words. (A PDF cannot exceed 100mb in size)
Up to 20 sources may be included in a notebook (which means a total of 4 million words may be in a single notebook).
Supported file types are Google Docs, PDF, text files and text pasted into the chat box.
For more information check out:
To upload a source, click on the “+” (plus sign) next to the “Sources” label in the left-pane.
A pop-up will appear where you select the type of file you are adding. When you select a PDF file, for example, a file chooser window appears. Below is the list of the resources I am using.
One thing to notice is that I needed to split a couple of PDFs into two parts. That is because the PDF exceeded the 200,000 word limit. I simply edited the PDF by saving half pages into a “Part 1” and the other half into a “Part 2”. This is easy using the MacOS Preview application.
Once all files are uploaded, ensure all are selected so that they are leveraged by NotebookLM AI when answering prompts.
At this point, you are ready to begin asking the NotebookLM AI for insights based on your authoritative resources.
CISO Questions
Here are a few questions a CISO may receive and how the NotebookLM AI answers:
Prompt: Provide a detailed template of an Incident Response Plan
Response:
Screenshot of the response.
Full text of the response.
Incident Response Plan Template
The provided sources do not contain a detailed template of an Incident Response Plan. However, they offer substantial information on the elements, best practices, and considerations for building a robust plan. Here's a consolidated view:
I. Purpose and Objectives
Clearly state the overarching goal of the Incident Response Plan.
Define what constitutes a security incident within the specific organizational context.
Outline the plan's scope, specifying the systems, data, personnel, and third-party entities it covers.
II. Roles and Responsibilities
Identify key personnel comprising the incident response team, including:
Incident Manager: The individual responsible for leading and coordinating the overall response effort. Consider designating a backup Incident Manager for redundancy.
Security Analysts: Personnel trained in incident analysis, investigation, and remediation.
System Administrators: Individuals possessing technical expertise to address system-level issues.
Legal Counsel: Experts to advise on legal and regulatory obligations.
Public Relations: Team members responsible for managing internal and external communications.
Clearly define roles and responsibilities for each team member, specifying their authority and decision-making power during an incident.
Establish clear escalation paths to ensure timely involvement of senior management when needed.
III. Incident Response Procedures
Preparation:
Establish a process for identifying and documenting critical assets to prioritize protection efforts.
Maintain up-to-date network diagrams and system inventories to facilitate understanding of the environment during an incident.
Develop and regularly test backup and recovery procedures for critical systems and data.
Establish secure communication channels for incident responders.
Conduct personnel training on incident response processes and procedures. Consider tabletop exercises to simulate realistic scenarios and assess team readiness.
Detection and Analysis:
Define methods for detecting potential security incidents, such as Intrusion Detection System (IDS) alerts, antivirus detections, or user reports.
Develop processes for receiving, validating, and categorizing incident reports.
Implement tools and techniques for incident analysis, including log analysis, malware analysis, and network forensics.
Establish criteria for determining the scope and severity of an incident.
Containment, Eradication, and Recovery:
Develop strategies for containing an incident to prevent further damage or spread. This may include isolating affected systems, taking down compromised services, or blocking malicious traffic.
Outline procedures for eradicating the threat, such as removing malware, patching vulnerabilities, or resetting compromised accounts.
Define steps for recovering affected systems and data, ensuring data integrity and restoring normal operations.
Post-Incident Activity:
Establish a process for documenting all aspects of the incident, including a timeline of events, actions taken, and evidence gathered.
Conduct thorough post-incident reviews (PIRs) or "lessons learned" sessions to identify areas for improvement in the incident response process.
Update the Incident Response Plan based on insights gained from PIRs and evolving security threats.
IV. Communication Plan
Define internal communication protocols, including who to notify and how, during various stages of an incident.
Establish procedures for communicating with external stakeholders, such as law enforcement, regulatory bodies, customers, or the public.
Specify approved communication channels for incident-related information.
V. Additional Considerations
Legal and Regulatory Compliance: Ensure the Incident Response Plan aligns with relevant legal and regulatory frameworks, such as data breach notification laws or industry-specific regulations.
Business Continuity and Disaster Recovery: Integrate the Incident Response Plan with broader business continuity and disaster recovery plans to address large-scale disruptions.
Regular Review and Updates: Establish a schedule for regularly reviewing and updating the Incident Response Plan to reflect changes in the threat landscape, technology infrastructure, and organizational policies.
The information provided here is for general guidance. You may want to independently verify the appropriateness and completeness of this template for your specific needs.
At the bottom of the response is a list of the citations for this response. Clicking on one of the citations pulls up the text of the cited document in the left pane.
Prompt: We outsourced our security operations center. What deliverables should we expect from them?
Response:
Screenshot.
Full text response.
Deliverables of an Outsourced SOC
While the provided source materials do not explicitly list the deliverables an organization should expect from an outsourced security operations center (SOC), they do offer insight into the considerations for outsourcing security operations and the types of services SOCs can provide.
Understanding Outsourcing Arrangements: When an organization outsources its SOC, it typically enters into a contractual agreement with a managed security services provider (MSSP). The specific deliverables will be outlined in this contract, which should clearly define:
Scope of Services: What specific SOC functions will the MSSP provide? For example, will they be responsible for 24/7 security monitoring, intrusion detection, incident response, threat intelligence, vulnerability management, or a combination of these?
Service Level Agreements (SLAs): What are the performance standards the MSSP is obligated to meet? SLAs should address metrics such as incident detection times, incident response times, and system uptime.
Reporting Requirements: How will the MSSP communicate information about security events, incidents, and overall security posture to the organization? This could include regular reports, real-time alerts, and access to security dashboards.
Common SOC Functions & Services: Based on the information provided, an organization with an outsourced SOC might expect deliverables related to:
Security Monitoring: The MSSP would continuously monitor the organization’s networks, systems, and applications for suspicious activity using tools like SIEMs, IDPS, and EDRs. Deliverables might include alerts on suspicious events and regular reports summarizing security events.
Incident Response: In the event of a security incident, the MSSP would be responsible for containing the incident, eradicating the threat, and recovering affected systems. They might provide incident summaries, forensic analysis reports, and recommendations for improving security posture.
Threat Intelligence: The MSSP might provide the organization with tailored threat intelligence relevant to their industry and threat landscape. This could include information about emerging threats, adversary tactics, and vulnerabilities. Deliverables might be threat intelligence reports or integration of threat feeds into the organization’s security tools.
Vulnerability Management: The MSSP may conduct regular vulnerability scans and penetration tests to identify and help remediate weaknesses in the organization’s systems. They might deliver vulnerability assessment reports and remediation guidance.
Important Considerations for Outsourced SOCs:
Communication and Collaboration: The organization should expect clear communication channels with the MSSP, including regular meetings, status updates, and prompt incident notifications.
Access and Visibility: The organization should ensure that they have appropriate access to security data, logs, and dashboards to maintain visibility into their security posture.
Organizational Knowledge: The organization should provide the MSSP with detailed information about their IT environment, critical assets, and business processes to ensure the MSSP can effectively protect the organization.
Key Takeaway:
While these are general expectations, the specific deliverables will vary depending on the specific terms negotiated in the outsourcing contract. Organizations should carefully define their requirements, expectations, and desired outcomes during the contract negotiation process.
Prompt: Describe in detail the best practice for managing software vulnerabilities.
Response:
Screenshot.
Full text response.
Best Practices for Managing Software Vulnerabilities
The documents provided offer a comprehensive framework for managing software vulnerabilities, emphasizing a proactive and multifaceted approach.
Key Principles
Vulnerability Management Program: A cornerstone of the approach is establishing a robust vulnerability management program.
Early Attention to Software Development: For internally developed software, integrating security considerations throughout the entire software development lifecycle is paramount.
Continuous Monitoring and Improvement: Given the constantly changing threat landscape, it is essential to continuously monitor for new vulnerabilities and adapt security practices.
Detailed Practices
Establish a Software Inventory
Maintain a comprehensive list of all software, including bespoke, custom, and third-party components, used within the organization. (NIST.CSWP.29.pdf)
This inventory is vital for identifying software that may be affected by newly discovered vulnerabilities. (Payment Card Industry Data Security Standard: Requirements and Testing Procedures, v4.0 March 2022)
Identify and Assess Vulnerabilities
Regularly consult reputable sources for information on newly identified security vulnerabilities:
Industry-Recognized Sources: These include vendor websites, industry newsgroups and forums, and security advisories from organizations like US-CERT. (Payment Card Industry Data Security Standard: Requirements and Testing Procedures, v4.0 March 2022)
National Cyber Awareness System (NCAS) Products: These products from CISA offer vulnerability summaries and updates. (Federal_Government_Cybersecurity_Incident_and_Vulnerability_Response_Playbooks_508C.pdf)
National Vulnerability Database (NVD): Maintained by NIST, this database contains information on known vulnerabilities and exposures. (nist.sp.800-61r2.pdf)
CISA-Managed Known Exploited Vulnerabilities Catalog: This resource, continually updated by CISA, lists vulnerabilities actively exploited by adversaries. (Federal_Government_Cybersecurity_Incident_and_Vulnerability_Response_Playbooks_508C.pdf)
Employ a risk-ranking system to prioritize vulnerabilities based on their potential impact:
At a minimum, all vulnerabilities categorized as high-risk or critical to the environment should be identified. (Payment Card Industry Data Security Standard: Requirements and Testing Procedures, v4.0 March 2022)
This risk assessment should consider the potential impact of the vulnerability and the organization's specific context. (Federal_Government_Cybersecurity_Incident_and_Vulnerability_Response_Playbooks_508C.pdf)
Engage in proactive vulnerability discovery:
Conduct security assessments of internally developed software to identify potential weaknesses. (NIST.CSWP.29.pdf)
Utilize automated tools or manual methods to review software code and identify potential security vulnerabilities. (Payment Card Industry Data Security Standard: Requirements and Testing Procedures, v4.0 March 2022)
Implement Timely Remediation
Prioritize the patching of critical and high-risk vulnerabilities within one month of their discovery. (Payment Card Industry Data Security Standard: Requirements and Testing Procedures, v4.0 March 2022)
For other vulnerabilities, apply patches within a timeframe determined by a risk assessment. (Payment Card Industry Data Security Standard: Requirements and Testing Procedures, v4.0 March 2022)
Use vulnerability and patch management tools for automation and tracking. (Federal_Government_Cybersecurity_Incident_and_Vulnerability_Response_Playbooks_508C.pdf)
If patching is not immediately feasible:
Implement compensating controls (e.g., network segmentation, access restrictions) to mitigate the risk of exploitation. (Federal_Government_Cybersecurity_Incident_and_Vulnerability_Response_Playbooks_508C.pdf)
Disable unnecessary services or functionalities to reduce the attack surface. (Federal_Government_Cybersecurity_Incident_and_Vulnerability_Response_Playbooks_508C.pdf)
Continuous Monitoring and Improvement
Establish ongoing monitoring of security alerts and advisories to identify emerging threats. (nist.sp.800-150.pdf)
Regularly review and update security configurations to ensure they align with best practices. (NIST.CSWP.29.pdf)
Conduct periodic reviews of the vulnerability management program to assess its effectiveness and identify areas for improvement. (m651001.pdf)
Additional Considerations
Secure Software Development Practices: Encourage the use of secure coding guidelines, threat modeling, and code reviews to minimize vulnerabilities introduced during software development. (Payment Card Industry Data Security Standard: Requirements and Testing Procedures, v4.0 March 2022)
Third-Party Software: Carefully evaluate software from third-party vendors, prioritizing those with established security practices. Consider vendors validated as meeting secure software development lifecycle standards. (Payment Card Industry Data Security Standard: Requirements and Testing Procedures, v4.0 March 2022)
Collaboration and Information Sharing: Participate in information sharing communities (e.g., ISACs) to stay informed about emerging threats and vulnerabilities. (nist.sp.800-150.pdf)
Note: These practices represent a synthesis of the information available in the provided documents. The specific implementation and prioritization of these practices may vary depending on the organization's specific context, risk appetite, and industry regulations.
Prompt: How do i see which executable files were run on a Windows computer?
Response:
Full text reponse.
Tracking Executed Files on Windows
The provided documents offer some guidance on identifying potentially malicious activities on a Windows computer, including methods that can be used to reveal what executable files have been run. While there isn't a single, foolproof method detailed to achieve this with absolute certainty, using a combination of the following approaches, drawn from the source material, can provide valuable insight:
Windows Event Logs: These logs are repeatedly highlighted as a crucial source of forensic information within the context of incident response. They can contain records of process creation events. Enabling the "Audit Process Creation" policy, as mentioned in one of the documents, is essential for ensuring these events are logged.
Command-line Logging: One document emphasizes the importance of "Include command line in process creation events" being enabled, stating that "capturing process command line information in event logs can be very valuable when performing forensic investigations of attack incidents." By enabling this setting, you enhance the information captured in the event logs, making it easier to see exactly which executables were run and with what parameters.
PowerShell Logging: Given the significant role PowerShell plays in system administration and, unfortunately, malicious activity, its logging capabilities are noteworthy. The documents recommend enabling "Turn on PowerShell Script Block Logging" and "Turn on PowerShell Transcription", which can provide a record of PowerShell commands executed, including those that might invoke executable files. However, it's essential to be aware of the sensitivity of the information captured in these logs, as they might contain credentials or other sensitive data. Implementing appropriate access controls and security measures, such as "Protected Event Logging", is recommended.
Analyzing for Common Adversary Tactics, Techniques, and Procedures (TTPs): The documents highlight the importance of understanding common TTPs in identifying malicious activity. For instance, understanding that adversaries often use techniques like "Account Manipulation," "Scheduled Task/Job," and "Valid Accounts"for persistence can guide your analysis. By examining the tools and logs associated with these TTPs, like "Host event logs," "Authentication logs," "Registry," and "Scheduled Tasks," you might uncover evidence of executed files, especially those designed for persistence.
Third-Party Tools: The documents mention various third-party tools frequently used in incident response and digital forensics that may offer more advanced capabilities for tracking executed files. These tools, like Volatility, procmon, Sysmon, and OS Query, are not explicitly detailed in the provided material. You would need to consult their respective documentation or other resources for guidance on their use.
Time Synchronization: While not directly related to viewing executed files, one document stresses the importance of synchronized host clocks in forensic investigations. This synchronization ensures that timestamps across different logs and systems are consistent, simplifying the process of correlating events and building a timeline of activities. This is particularly important if you're trying to track the execution of files across multiple systems.
Note: The level of detail available and the methods for accessing these logs and configurations might vary depending on the specific version of Windows in use. You may want to consult Microsoft's documentation or other reliable sources for instructions tailored to your Windows version.
I could go on and on with multiple prompts but you get the idea.
Conclusion
This article is meant to show the use of a user-friendly RAG AI application, NotebookLM, to leverage the knowledge regularly used by CISOs. The prompts illustrate how high-level and low-level technical information can be easily extracted from this knowledge base using natural language prompts. Can this fully replace a CISO? No. However, it can help IT managers and other organizations that may not have a CISO. They can obtain guidance based on authorative resources at any time, versus gambling with a knowledgebase based on the whole “polluted” Internet. RAG-based AI applications have been the most useful products for small-to-medium businesses since the beginning of the generative AI revolution. NotebookLM is excellent and among the easiest ways to leverage your research documents to extract useful information using natural language. However, it is not perfect. It is listed as “Experimental” by Google, so we do not know its longevity. Regardless, NotebookLM gives us a clear glimpse into the benefits of a RAG-based AI application. I look forward to seeing what comes next.
