Patch & Vulnerability Management Policy¶

Version history¶

Version Number	Date	Description	Created By	Approved By
0.1	23/Apr/2024	Initial Copy	[Name] [Name]
0.2	18/Jun/2024	Approved	[Name] [Name]	[Name]
0.3	28/Aug/2026	Knowledge kernel, AI/agents, control alignment	Knowledge steward	[Name]

Purpose¶

The purpose of this policy and procedure is to define the process of identifying vulnerabilities within the internal and external environment, identifying the applicable patches and updates to close these vulnerabilities, and outlining the process to implement the patches and updates post- appropriate testing.
While many of these processes were already in place within the organization, this policy documents both existing and new processes.

Scope¶

This policy and procedure apply to the entire infrastructure of tecciance, including both the internal and external network and server environments.
This policy and procedure cover the following areas of tecciance:
Desktop/Laptop operating environment.
Server operating environment within tecciance
Server operating environment on the cloud
Network devices and equipment installed within tecciance and on Cloud
Code repository in development, testing, and production environments.

Responsibilities¶

The Software Development team and Information Technology Infrastructure team members will be responsible for periodically identifying significant security vulnerabilities that may impact tecciance applications and assets. These teams will also make recommendations regarding the timeline for patch installation based on the severity of the threat.
The Information Security Team will continue to monitor the status of each discussed alert, ensuring to track any changes in the alert status (e.g., exploit availability, patch availability) and update the temporal score of CVSS to reflect these changes. Such updates may raise or lower the initial CVSS score, and any changes to an alert will be tracked by the IT Infrastructure Team.
Security patches or updates must be manually/automatically applied after proper testing to each vulnerable host by the respective system owners within a specified time based on the priority ranking assigned to each patch as outlined in the next section.

Priority Ranking¶

All updates will be ranked as P1-P4.
Priority ranking depends on the CVSS score of the vulnerability. The CVSS score is determined based on the access conditions and impact of a vulnerability, as well as time-dependent qualities of a vulnerability, such as patch and exploit availability. The Information Security Team is responsible for assigning a CVSS score to an alert, which is then scored in the alerts database and discussed during the scheduled Security Alerts Team meeting. All vulnerabilities with a CVSS score equal to or greater than four must be addressed.
A priority ranking will be given to an alert based on the CVSS score. Any borderline alerts will be adjusted based on the consensus of the Information Security Team members. The alert's priority will be assigned based on the following table.

CVVS SCORE	Priority	Patch SLA
Normal	P4
Medium	P3
High	P2
Critical	P1

Vulnerability Identification¶

There are several methods to identify security vulnerabilities for both software applications & hardware devices. tecciance must consider the following sources to identify security vulnerabilities applicable to its information resources:
Regular Interval (at least yearly) External Vulnerability scans performed on all the public- facing IP addresses using an approved scanning vendor.
External Network penetration tests are conducted at least annually.
External and Internal Vulnerability conducted after any significant infrastructure or application upgrade or modification.
External and internal penetration testing is conducted after any significant infrastructure or application upgrade or modification.
Actively monitoring industry publications to identify zero-day vulnerabilities and other security issues. E.g., security focus, vendor security publications, etc.
Review of daily and real-time virus scanning logs.
Security issues reported from a review of security logs.
Security issues reported because of Internal/External Audits

Vulnerability and security patch management¶

A vulnerability management tracker must be maintained to track the progress of fixing the identified vulnerabilities. Identified vulnerabilities must be categorized with their respective severity ratings i.e., High, Medium, or Low, and the Risk Ratings as per the priority table above, so that they can be patched /fixed accordingly. All the vulnerabilities should be validated to isolate false positives. Following are the guidelines on applying security fixes based on the severity and risk rating of the vulnerabilities and availability of exploits.
A vulnerability exists if an attack is underway: This would fall under the P1 Priority category and in this situation, the security patches/mitigation steps should be performed immediately based on availability and facility of implementing the fix.
A vulnerability exists and an attack is determined to be imminent: This would fall under the P2 priority category and in this situation, the security patches/mitigation steps should be applied each Saturday.
A vulnerability exists and an attack is determined to be not imminent: This would fall under the P3 priority category and in this situation, the security patches/mitigation steps should be applied each Saturday.
All other vulnerabilities: This would fall under the P4 priority category and in this situation the security patches/mitigation steps should be applied within the agreed time based on testing results.
Security patches released by Vendor: All applicable security patches carrying a high severity rating should be evaluated and applied within the agreed time based on testing results.
Missing operating system patches: Missing patches identified because of vulnerability scanning must be evaluated and applied based on the above guidelines.

Note: All the patches/fixes must be evaluated before being implemented in the production environment.

Policy¶

Patches shall be identified, selected, and finalized for implementation based on relevance and criticality to the concerned infrastructure or device, or application.
New patches shall be evaluated for relevance and criticality to the Organization prior to implementation.
Consideration of non-applicability of patch shall be verified by the appropriate person or authority.
All patches shall be adequately evaluated before deploying into the live environment, wherever possible.
In the case of OEM or Supplier provided or recommended patches, third-party reviews or results may also be referred for adequacy.
Wherever possible, deployment of patches shall be automated to ensure uniform application of configurations, policies, and patches at an organization level.

Procedure¶

For Laptops/Desktops and Other Computing Devices¶

The latest critical/security or recommended patches for laptops/desktops/other computing devices shall be installed on an availability basis.
The OS vendor (OEM) shall send notifications of all such available and applicable patches for the devices. Users shall deploy the patches on their systems on a priority basis. In situations where patch deployment requires administrative access to the system, the IT Team shall deploy the patch through a manual or automated process.
For all patches affecting significant users, the IT Team shall evaluate the relevant patch on one sample system and give permission for deployment only if testing is successful.
The IT Team shall conduct periodic manual checks to ensure that all relevant patches are updated on the systems. MS Office and OS (Windows, macOS, Ubuntu) should be updated to the latest version where applicable.
Records of patches deployed on individual systems/desktops/laptops/computing devices shall not be maintained by the IT Team, but the relevant records shall be available at the system level.
Patches for applications, tools, and utilities used on laptops/desktops/computing devices shall be deployed by individual users on an as-needed basis.

For Anti-Virus and Anti-Spyware/Malware Software¶

The latest updates for anti-virus, anti-spyware, or anti-malware software or utilities shall be installed on an availability basis.
The vendor (OEM) shall send notifications of all such available and applicable patches. The IT Team shall identify and evaluate the patches on sample systems as required. The IT Team shall push the updates/patches to all systems within the network.
If a system was not available or connected to the network when such a patch was pushed, it is the user's responsibility to update the patch or obtain the update from the IT Team. The IT Team shall conduct periodic manual checks to ensure that all relevant patches are updated on the systems.
Records of patches deployed on individual systems/desktops/laptops/computing devices shall not be maintained by the IT Team, but the relevant records shall be available at the system level.

For Networking Devices and Equipment¶

Responsibility for updating all networking devices and equipment within tecciance infrastructure shall lie with the IT Team. Responsibility for updating all networking devices and equipment outside tecciance infrastructure (such as in AWS) shall also lie with the IT Team.
The relevant team shall keep track of all relevant patches and updates released for the networking devices and equipment.
The relevant team shall evaluate the patch in a similar environment to ensure adequacy and applicability.
Records shall be adequately maintained. Prior notifications/notices of such patch management shall be given to relevant users, stakeholders, and parties likely to be affected by this activity.
Records of completion and post- completion testing shall be maintained. Where a patch seems critical or significant, Major or Critical Change shall be identified, and relevant Change Management processes shall be followed.

For Servers¶

Server-level patches include OS Level patches, Application-related patches, as well as Library-related patches. The responsibility for identifying, evaluating, and deploying patches on servers shall remain with the IT Team.
For identifying vulnerabilities on the library level, automated tools shall be run by the IT Team monthly. The results and findings after running the tool shall be categorized as High, Medium, and Low by the tool and the IT Team.
Similar automated/manual scans shall be initiated by the IT Team for Linux OS-level vulnerabilities (AWS Patch Manager) or Application Services running on DDRX-Web, DDRX- Backend, and DDRX-Jump Servers.
Such scans shall be conducted monthly. The results of such scans, along with categorized vulnerabilities, shall be reported to the ISMS Head. The patches/updates for all vulnerabilities shall be identified by the IT Team and reported to the ISMS Head for approval. Where required, the patches/updates shall be evaluated within the test environment. After adequate testing and relevant approval from the ISMS Head, the IT Team shall update the patches in the live environment.
Post-deployment tests shall be conducted to ensure that the functioning is not affected due to patch management. Records of all patch management shall be maintained.

General Guidelines for Patch Management¶

All new devices must be patched to the current patch level, as defined by the vendor, before connecting them to the live network.
The IT Team shall subscribe to all vendor portals, security groups' websites (e.g., Microsoft, CERT-India, Security Focus) to receive information about patches released by the vendors. Where possible, the IT Team shall deploy an update tool (e.g., WSUS - Windows Server Update Services) within the internal environment.
The tool allows administrators to manage and distribute updates through an administration console.
Patches shall be downloaded from valid and authentic sites (e.g., vendor releases, OEMs) only.
All patches will be evaluated in a proper test environment before deployment in the live environment. The testing environment should be built to simulate most of the targeted platforms. Patches shall be applied after business hours with prior notification to respective users, where applicable.
Upon successful implementation of patches, respective systems shall be monitored for their performance. Previously functioning operations and utilities on the target platform should continue to operate as before.
In case of significant issues/problems, it should be possible to remove patches successfully.

References¶

Vulnerability Assessment Reports and Results
Patches/Updates notifications/reports received from OEMs and Technology Vendors Patches/Updates implementation reports received from Platform vendors.
Records maintained via email Approval records, as applicable.
Change Management Policy and Procedure

¶

Artificial intelligence, software agents, and organizational knowledge¶

This section is added in version 0.3 so the policy applies equally to employees and to software agents, and so reusable knowledge stays provenanced.

Software agents, bots, service accounts, CI jobs, and coding assistants are identities. They are in scope of this policy wherever people are.

Every retrieve or use of organizational knowledge or classified data requires a verified identity, a stated purpose, and a classification ceiling. Missing purpose is deny.

AI may extract, draft, rank, or propose. AI shall not approve access, classify or reclassify information, set reuse rights, waive a control, merge to a protected branch, or treat search ranking as truth.

Approved reusable knowledge is a governed claim with source, owner, lifecycle, applicability, and limitations. Raw chat, tickets, and scanner output are not approved knowledge.

Embeddings, summaries, caches, and compiled agent skills are derivatives. Withdrawal, reclassification, or destruction of a source shall propagate to derivatives.

Secrets, credentials, production data dumps, and Restricted (including client/PHI) material shall not be pasted into public generative-AI services or stored in vector indexes unless an authorized path and agreement exist.

HIPAA-regulated PHI is out of default scope. Enable the HIPAA pack and a business-associate path before any PHI is processed by agents or knowledge indexes.

Change to a must procedure (including knowledge used by agents) is a change under the Change / Release procedure and SOC 2 CC8.1. Agents cannot approve that change.

Dependencies of agent frameworks and CI images are in the vulnerability programme. Critical findings block merge unless an exception is recorded.