Host or Operating System Security

In normal case application work on the top-up of the operating system and in efforts to achieve total security in such arrangement to be based on the flawed assumption that adequate security can be achieved in applications with the basic security at the operating system level. While in other hand reality is that secure applications demand secure operating systems, and tackling application compromises by operating system enforced controls should be considered as an effective approach.

Operating System Product Security Certification and Accreditation:

The almost 99.9999% of us means Cybersecurity architects / Administrators / Managers / Engineers don’t have a lab, sophisticated equipment, and arrangement to test the security of an operating system product in depth and our executive management will go crazy if demand for such facility. Hence we have to trust the reputed agency and third-party evaluators testing operating system security providing assurance level and other ratings to these products. Let go through, in short, some of legacy evaluation criteria so will able understand the development of moderns evaluation methods.

Trusted Computer System Evaluation Criteria (TCSEC):

First published in 1983 and later updated 1985, The TCSEC normally referred to as ‘Orange Book’, was a Government of US Department of Defense Standard for the military and government computer system. TCSEC sets basic standards for implementation of security protection in computer systems. If we talk about the specification and features of this standard it is strongly focused on confidentiality with low focus on Availability and Integrity aspects. Although it is superseded by Common Criteria, still it influenced a lot in the development of other product evaluation criteria, and some of its basic approach and terminology continues to be used in the industry.

Summary of Orange Book Division Criteria:

The Information Technology Security Evaluation Criteria (ITSEC):

ITSEC is a UK scheme in which security features of IT systems and products are tested independently to identify logical vulnerabilities. It combined and harmonized the national criteria produced by the United Kingdom, Germany, France and the Netherlands after the publication of the TCSEC criteria in the United States. The ITSEC was first published in May 1990 in France, Germany, the Netherlands, and the United Kingdom based on existing work in their respective countries. Following extensive international review, Version 1.2 was subsequently published in June 1991 by the Commission of the European Communities for operational use within evaluation and certification schemes. The ITSEC has been largely replaced by Common Criteria, which provides similarly approach for product evaluation.

With evaluation criteria, consumer or vendor has the ability to define a set of requirement from the menu of the possible requirement into a Security Target (ST) and vendors development products (the Target of Evaluation or ToE) and have them evaluated against that targets. Unlike TCSEC, it also addressed a wider range of security needs, including integrity and availability requirements. ITSEC Assurance level can be defined as a level of confidence that evaluator has that the product not only meet the functional requirements but that it will continue to meet those requirements. ITSEC defined six different levels of assurance, each one more difficult to achieve than the last.

Common Criteria

Common Criteria represents IT security criteria that are broadly useful within the international community. We see how TCSEC and ITSEC were developed. In the succeeding decade, various countries began initiatives to develop evaluation criteria that built upon the concepts of the TCSEC but were more flexible and adaptable to the evolving nature of IT in general. In Canada, the Canadian Trusted Computer Product Evaluation Criteria (CTCPEC) version 3.0 was published in early 1993 as a combination of the ITSEC and TCSEC approaches. In the United States, the draft Federal Criteria for Information Technology Security (FC) version 1.0 was also published in early 1993. Work had begun in 1990 in the International Organization for Standardization (ISO) to develop a set of international standard evaluation criteria for general use.

The publication of Common Criteria as ISO/IEC 15408 standard provided the first truly international product evaluation criteria for security properties of IT products. It adopted a similar approach to ITSEC by providing a flexible set of functional and assurance requirements, alike ITSEC, it is also not very restrictive in nature as TSEC had been. This product evaluation criterion focused on standardizing the general approach to product evaluation and providing mutual recognition of such evaluation all over the world. The Common Criteria introduced Protection Profiles (PP), these are a common set of functional and assurance requirement for a specific category of vendor products used or deployed in a particular type of environment. The vendor products (Referred to as ToE) is then examined against this specific profile by third-party evaluation labs using Common Evaluation Methodology (CEM).

Evaluation Assurance Levels represents the degree of confidence that specified functional security requirements have been met by the vendor product.

The keynote to take here is that two products assigned the same level of EAL level shall not be compared as their functionality may differ even though both are from the same category but functionality may in common.

Operating System Secure Implementation and Operations:

As we already covered in this article that what is an operating system, what are its essential components, why it is important to secure it, and evaluation security of an operating system as a software product. Although like any machine, system or software and regardless of how much it is secure by design. if we do not use it with certain security practices it will not deliver the intended level of security objectives. Once we selected a secure operating system product it is essential to acquire, install, configure, and operate it securely. Below is a collection of some good practices regarding using an operating system. We should use these practices to keep the operating system environment secure.

Secure Hardware

Secure Physical Access to the computer system hardware and networking infrastructure.

As an information security practitioner focusing on every aspect of securing system is quite important, one of the most overlooked area is physical security. Regardless of countermeasures or controls applied at the logical level, if an intruder or malicious actor able to reach equipment physically it makes logical security null & void.

Reader excuse me to deviate from the track and sharing my specific experience of system audits, have seen many system engineer/administrator to claim and give excuse in audits that they secure the system in a way that even though physical security is not strong enough, but at a logical level, everything in place and intruder or malicious actor will not able to access the system. But hardware keylogger and their types and their capability to hide itself is something which breaks such myths.

There is great chance of success for a malicious actor, who have physical access to hardware of OS to plant such spying devices especially Keyboard and external keyloggers, and that is one attack vector only, there are many sophisticated devices available in the market for an intruder or malicious actor once they have physical access to your critical systems. Hence, folks please mindful about the physical security of your critical hardware always.

Secure BIOS, UEFI, Firmware, and Diagnostics Interfaces

Secure Binary Input Output System (BIOS), Unified Extensible Firmware Interface, Device Firmware and Diagnostics & Management interfaces.

Once the hardware is placed at a secure facility, we should start thinking securing hardware programs directly control and monitor system hardware such as BIOS, UEFI, Firmware and other OEM embedded programs in hardware, as they are on default OEM configurations, few examples of such programs are Dell’s DRAC (Dell Remote Access Control), Sun’s (now Oracle) ILOM (Integrated Lights Out Manager), IBM’ IMM (Integrated Management Module), HP’s ILO (Integrated Lights-Out), and Intel’s RMM2 (remote management 2). As it depends on your procurement that which programs will be there still many OEM products include a basic license of such programs by default. Below are some good practices, a Cybersecurity architect / Administrator / Manager / Engineers shall employ for OEM embedded hardware programs:

• Limit access to such interfaces at the network level, and preferably separate these interfaces from the normal production network.
• If supported, enable power-on password (POP) and secure boot option at BIOS, UEFI and any other applicable hardware program.
• Enable logging and monitoring as per features available on the program and secure logs for later review.
• Ensure these programs software codes up to date all the times.
• If any hardware OEM embedded programs accessible on a specific protocol/web console/java console/SSH etc. (Normally Remote support, Diagnostics and Management Interfaces are accessible) employ protocol or technology-specific (HTTP/SSH/Java etc.) security controls.
• Ensure these interfaces and programs are part of your IT inventory maintained for a risk review, information security review, vulnerability assessment and penetration testing up to extent practicable.

Acquire Securely

Acquire an Operating System Product from a legitimate and authentic source. And verify the software’s legitimacy before installation.

An OS installation performed using unverified software media have a tremendous impact on system integrity which may intern lead to an impact on confidentiality of data and availability of the system. Hence, its important to obtained OS software from a legitimate source, many of organization having good high-level control over system acquisition, development, suppliers and vendor product & service delivery still granularity in control implementation should be focused. There was a time when operating system software delivered in CD/DVDs prepared in OEM facility and these discs are not re-writable, though nowadays electronics methods replaced software media delivery, though there is not much trouble from OEMs in both the methods. Large scale project implementations require software distribution and licenses sharing among multiple peoples and third part entities and maintaining the integrity of software media is a challenge, below is recommendation may reader implements with correctly.

• Post downloading and verifying software from OEM web portal, whenever software distribution and circulation performed sender shall use a secure official channel and provide hash key along with software image to recipients.
• Organization and projects normally maintain software repositories for safekeeping and easy distribution of software images, such repositories should be reviewed regularly and proper inventory should be maintained to detect any unauthorized software entry.
• System engineers and any other personals have a valid reason and authorization to acquire software shall be educated to use legitimate and authorized channels and the right process to obtain software images.
• Software repository or any other software distribution system used with organization/project and data contained by such system shall be part of inventory maintained for an information security risk review.
• Software repository or any other software distribution system used shall be part of information security review, vulnerability assessment and penetration testing up to extent practicable.

Install Securely

Install operating system using secure installation methods only

Normally organization and large scale projects perform bulk installation of Operating System Software on hardware and virtual machines and this includes a good amount of automation as well. Either an organization select to perform OS installation one by One on each machine or decides to perform automated bulk installation, a secure installation procedure shall be adopted for installation. An organization or Project shall establish a secure installation procedure and some key points to consider in the secure installation procedure is as below

• Enable OS security features by default: Enable OS firewall, Security features such as SELinux (Applicable for Linux only), etc. during installation. This activity requires close coordination with application team as some security feature may incompatible with Application suppose run top-up of OS.
• Post Installation Security Checklist: Post installation change/disable default user accounts, SNMP configuration, RDP/telnet/SSH etc. based on your InfoSec policy and requirements. Also, enable Antivirus System, Host-based Intrusion Detection/Prevention, Data Loss Prevention, etc. though it depends on your organization or project information security policy and requirement, that what all security features will be enabled and what all feature will be disabled or changed on a newly installed OS. Hence, we recommended to prepare a post Installation Security Checklist and comply to same before start using a newly installed OS instance. We recommend that this checklist should be prepared by the InfoSec team though activity shall be completed by the same execution team to avoid any gap.
• Check and Fix Missing Security Updates: Post Installation before system handover to application team or user all missing security updates shall be installed by same execution team or engineer then and there.
• Test Security: InfoSec team shall check and test every OS installation performed by execution team and verify Hardware Physical Security, Hardware OEM Embedded program security, Check security profile used, verify any needless software packages and service, OS security features used, Post Installation Checklist, Missing Updates, etc. InfoSec team should perform Vulnerability Assessment at least and Penetration Testing (if required by InfoSec Policy or Project Requirement) before granting handover of system application team or users. OS installation performed shall be added to inventory and regular Information security Compliance Review, Vulnerability Assessment, Penetration testing shall be performed.

Operating System Accounts

Limit the number of users and privileged accounts, Strong Password, Session Timeout, Encrypt password storage Files etc.on the Operating System.

User accounts of Operating system needed and used by Applications, System Service, and Users to execute instruction, run processes, and manage resources of the operating system in order to achieve intended objectives. Though the function of the operating system account is transactional hence having the right security control over OS account is quite important. Normally, activities and behavior of OS account controlled with by account policies. some important aspects of operating system accounts security include but not limited below recommendation.

• Ensure to change/disable default operating system accounts.
• Limit the number of user accounts on the Operating System. As unnecessary user accounts increase system complexity and may present system vulnerabilities.
• Ensure Session timeout on inactivity post login in enforced on operating system.
• Ensure Legal Notice and banner displayed to users and up to extend possible need user acknowledgement to continue login on operating system.
• User with no activity from long time shall be disabled automatically on operating system.
• Identify user and system account have a need to login OS and set them accordingly. All users should not have right to login in operating system.
• Ensure privileged users account parameters may not be manipulated easily.
• Ensure operating system software specific controls are employed to prevent privilege escalations.
• Ensure auditing and logging features enabled on operating system.
• Ensure that only a few trusted users have administrative access to Operating System. As fewer administrators make it easier to maintain accountability.
• Assign the minimum required access permissions for the account that runs the application. As If attackers obtain access to the application, they have the permissions of the user who runs the application.
• Develop and administer password policies that promote operating system security, which at least include below:
  1. Ensure password expiration or ‘Maximum password age’ is defined for account with operating system.
  2. User should not be allowed to set same password again, ensure ‘Enforce Remember password history’ is set to appropriate number.
  3. Ensure ‘Minimum password age’ is set, if a user want use its favorite password again. She/he can reset password continuously greater than the value of ‘remember password history’ and can reuse its favorite password again. To restrict this setting ‘Minimum password age’ is good option, but it has a risk that if user password compromised She/he can’t change password until ‘Minimum password age’ is expires
  4. Ensure password expiration warning displayed to users well before their password expires
  5. Accounts that are inactive for many days after password expiration should be get disabled automatically.
  6. Ensure manipulation with password change dates/records, password age, password complexity requirements etc. is possible with ordinary means.
  7. Ensure complexity of password for accounts including ‘Minimum password length’ and complexity requirements’
  8. Ensure password file store passwords using irreversible encryption and ensure access to file restricted.

Restrict Access Privileged Utility Programs

Restrict access to Disk Management, Network Management, User Management etc.

A Utility program is a software which performs a specific task within Operating System Environment, usually related to managing associated operating system resources. The operating system comes with variety utility programs such as default email clients, Calendar, Calculators, Text Editors, Image Viewer, and a suit of OS administration utility programs such as Disk Management Programs, Network Management Programs, OS firewall management programs etc. Utility Programs differ from applications mostly in terms of size, complexity and function. For example, word processors, spreadsheet programs, Web and database applications are considered applications because they are large programs that perform a variety of functions not directly related to managing resources of the operating system. Although they focused on providing certain services useful for Operating System users.

Privileged Utility software or programs (PUP) is system software designed to help to analyze, configure, optimize or maintain associated resource with Operating System. Privileged Utility software or programs require high level access to operating system or administrative privilege to do their jobs. Hence, controlling access to PUP, use of PUP, and functionality of PUPs is an important aspect to keep operating system in secure state as most computer installations have one or more privileged utility programs that might be capable of overriding system and application security controls and shall be restricted and tightly controlled.

• All utility programs shall be identified and a segregation between Normal and Privileged utility programs shall be performed.
• Ensure utility programs segregated from applications software.
• Remove or disable of all unnecessary utility programs which is not required to achieve business objectives.
• Up to extent possible identification, authentication and authorization methods should be used for Privileged Utility programs.
• Limit use of Privileged Utility Programs to the minimum to trusted and authorized users only.
• Use of Privileged Utility Programs on Ad-hoc basis by ordinary users shall be govern by an authorization process and for specific duration only.
• Ensure comprehensive logging on use all use of Privileged Utility Programs.
• Ensure authorization levels are defined and implemented for Privileged Utility Programs;
• Implement segregation of duties on use Privileged Utility Programs e.g. users who have access to applications on systems shall be restricted to use Privileged Utility Programs.

File System Security

Control Permission and ensure data security – Should be Deny by default, and grant permission on the need to know basis only, File system Backup & Encryption.

A file system is a program or technique designed to be used by the operating system to store, retrieve and update a set of files. The term also identifies the data structures specified by that technique, responsible for organizing files and directories, and keeping track of it. Hence, the file system can be supposed of as an index or database containing the physical location of every piece of data on a hard drive. It is a software program that takes commands from the operating system to open, close, read and write the files.

The file system allocates and manages the available space of the device(s) and manages access to the directories and files. As we understand from the above details that the file system has a crucial role in access control over variety of objects of the operating system. Some aspects are as below:

Files and Directory Permission (Typically ACLs):

• Assign access to users on file system objects adhering to a well-reviewed authorization schema, which should be based on the need to know and least privilege only to perform business objectives.
• Critical and Sensitive objects of Operating System such as boot partition, core OS files, Files containing user account details and passwords etc. shall be set to deny access by default for all users except system administrator.
• Access to file system objects (Files, Directories, and Partitions (Volumes)) shall be strictly on the principle of least privilege only.
• Disable default sharing of the folders and directory such as $ sharing in windows systems.
• Based on organization policy user may be allowed to configure addition permission as the process or data owner/custodian, though system administrator should have the right to override such configuration with proper authorization.
• Permission such as world readable/Writable, Access to Everyone shall be restricted and shall be granted for special purposes only such as public website content files.
• The file system should not have any unowned/orphaned objects such as directory, File and links, and every object should have assigned owner.
• Ensure no ungrouped files or directories exist, such condition occurred when user or group deleted but associated file not removed by system administrators.
• Disable the use of removable media and mounting/automounting a new file system on the operating system and it shall be denied by default for all users except system administrator.
• Ensure regular file system consistency checks, review users account permission on filesystem objects.

Filesystem Backup:

Almost all modern operating system regardless of their class and type, come up with default programs which can monitor consistency and health of filesystems, and able repair and recover from filesystem error still relying on only operating system internal controls for the mission-critical system is not advisable and employing backup and recovery strategy is highly recommended. Although, employing an exact strategy wither using a third-party commercially available or an open source backup tool, or using an operating system function, or inbuilt backup feature of OS may vary with size and/or financial strength and/or policy of that particular organization. Still, we recommend below minimum controls:

• A well-reviewed formal back up policy shall be used to govern the backup process.
• The backup policy shall clearly outline the inclusion and limitations of a backup executed by using policy.
• The backup policy shall clearly define the schedule, frequency, type of backup to be performed.
• The backup system shall be able to successfully restore the last known good state captured by the backup system in line with its schedule and frequency.
• Information security controls such as applying access controls, encrypting of backup data and its metadata etc. should be applied on backup data and the backup system as per organization information security policies.
• The backup system used shall be part of information security review, vulnerability assessment and penetration testing up to extent practicable.
• Regular backup and restore drills and testing should be done to ascertain the proper functionality of the backup system.

Files, Directories or Filesystem Encryption:

All modern operating system supports industry standard encryption methods for files, directories, and volumes. Encryption addresses multiple information security risks and provides an additional layer of defense with existing security controls of the Operating System. Operating System may provide encryption of data at filesystem level by two means using its native encryption methods which normally encrypt whole partition/volume at OS, another way is to use some reputed commercial or freeware open source tool which have their own multiple features. Though using encryption is very essential considering the latest threats to data at file systems level.

Securing Operating System Service and Associated Processes

A bare metal Operating System provides various kinds of services to users and to the operating system programs, and the third-party application programs (that run on an Operating system). A service is a process which runs in the background and does not interact frequently with the user, and normally it automatically gets as stared as part of an operating system. Though manipulation may be possible on the way process starts. A service normally runs an instance of a service program. As an exact set of services differ for the different flavour of the operating system, a limited high level of categorization of operating service as below:

• User Interface services
• Program Execution services
• File system manipulation services
• Input / Output Operation and Control Services
• Network Communication Protocols services
• Resource Allocation Services
• Error Detection and correction services
• Resource Accounting services
• Security and protection services
• Other services

There is to some essential concepts applicable for securing services is as below:

Minimization of Services:

Only a minimum number of services and associated processes (instance of service program) shall run on the operating system. Please note more service will lead to more vulnerabilities and more risk to the system.

Access Control on user interaction with services:

Not all users should have the right to add, remove, modify, start and shut down a service or its associated processes. The different operating system offers a different way to implement access control for service and processes.

Use of authentication, authorization, Accounting for services:

Based on the type of services and its functions Authentication, Authorization, and Accounting (AAA) should be implemented. Just put more light on this a Remote Desktop Service of Windows family of the operating system or Secure Shell Service (SSH) of Linux Family of the operating system are the example on which AAA should be implemented. More example may possible although Cybersecurity architect / Administrator / Manager shall plan this based on Operating System type and its service.

Use of encryption:

This is not applied uniformly on all services and its processes, although up to extent practicable the use of encryption shall be employed on interaction one service to another service and interaction of users with services. Employing the use of encryption on HTTP, FTP, Email, Terminal Services, Remote Desktop services etc. a limited example on this.

Ensure Monitoring of the state and status of services:

Monitoring state and status of service is crucial in operating system security as security administrator disable many system services to keep the operating system secure from internal and external threats. A hacker or internal user (intentionally or externally) may change state and configuration parameters of services which could result in breach system security. Hence, regular monitoring services state and status is an important activity to maintain OS security.

Vulnerability and Patch Management

Assess, Discover, Verify, and Mitigate Software Vulnerabilities

Operating system OEMs and users’ communities (for Open Sources) identifies various bugs, functionality issues, security vulnerabilities etc. in operating system software and releases software updates, advisories and workarounds to closed those vulnerabilities. Cybersecurity architect / Administrator / Manager shall keep a track on such developments and patch/configure workaround earliest to secure system. The organization should define a clear Vulnerability Management Policy as part of IT system information security policies, which should include a patch management process with below minimum controls:

• Ensure that updated information of newly discovered vulnerabilities in the used operating system and released patches, OEM advisories, and recommended workarounds will be delivered to Cybersecurity architect / Administrator / Manager to act in a timely
• Cybersecurity architect / Administrator / Manager shall subscribe email notifications from Operating System software OEMs, ensure support contract with Operating System software OEMs or suppliers for such services, or they may partner with cybersecurity specialist organization for such updates.
• Identification of missing software updates and Vulnerabilities: A robust process should be established to identify missing patches and operating system updates on a regular basis.
• Categorization, Prioritization, Testing and Responding: A robust process should be established to react on identified vulnerabilities and missing security updates. All identified issues should be categorized based on its impact on system security and stability then prioritized for closure based on categorization. Before making any update, configuration, or change in production operating system instance it should be tested on isolated testing operating system instance. Once assured that whatever mitigation activities planned working correctly, then it should be applied to the production operating system instance.
• Continuous Monitoring: All operating system instance in an organization should be monitored for missing software updates and vulnerabilities on a regular basis.
• All operating system instance working in an organization environment shall be subject to information security compliance review, vulnerability assessment and penetration testing up to extent practicable.

Operating System Minimization

Minimizing operating system is one the most crucial concept to employe while managing operating system security. While many of aspects of minimizing operating system already covered in previous sections of this article though minimizing below will help a lot to enhance the security of operating system instances, as a minimum the operating system will be on hardware lesser the vulnerabilities will emerge. Although, only components contributing to vulnerabilities on the operating system need to minimize, not components enhancing security such as OS firewalls, Access Control roles etc.

• Minimizing software installation either OS packages or third-party software.
• Minimize the number of users and system accounts.
• Minimizing the number of utility programs on the operating system.
• Minimizing the filesystem access to users.
• Minimizing number running processes on OS.
• Minimize Local and Network-based services from OS
• Minimize open ports listening from OS.
• Minimizing third-party applications and programs.

Logging and Monitoring:

Analyzing system logs and events provide insights into the critical security-related information. Logging appropriate events of systems and storing it securely for near-realtime or later review is one of the most essential aspects of system security. Cybersecurity Architect / Administrator / Manager shall provide importance to securing logs and shall invest diligent efforts to configure logging parameters of the operating system.

• Set Logging parameters OS: Set size/quota of logs storage, configure retention of logged data, as per requirement and organization policies.
• Configure correctly what to log: Different OS platforms offer different ways and level of granularity in logging. Though login and logout, failed login attempts, account creation, account deletion, account modification, remote terminal logging, changes to user permissions, suspicious network packets, SSH Access etc. are some examples. While my thumb rule is that “Acess to and/or Transection with OS objects by all subjects should be logged in accordance with system processing capacity and up to extent practicable”
• Secure the logging configuration file. The configuration file contains settings that, if changed, can compromise the reliability of the log system. For example, setting the log level incorrectly may cause some failures not to be logged.
• Store Logs at secure Storage: Storing logs at secure storage with restrict access control is vital for post facto analysis of events on the operating system. In some cases, it might be a piece of legal or forensic evidence. Whether keeping logged data on local storage or passing it to remote Syslog server or storage in both cases implementing specific controls are important to avoid tempering, deletion, and modification. While we recommend to always pass logs to remote storage with restrict segregation duties in system admin of Syslog server from other administrator managing operating systems.
• Time Synchronization: In a modern computer system, time synchronization is critical because every aspect of managing, securing, planning, and debugging a computer involves determining when events happen up to the accuracy of a fraction of seconds. The time source of the operating system shall be in synch with a valid time source, as invalid or mismatch in time may nullify the purpose for which these logs securely collected. Also, mismatch in time or unsync time definitely reduce validity as evidence of an incident also huge effort and time will be required to correlate logs with other systems logs and to the chain of incidents.
• Review, Auditing and Accounting of logged events: Regular or continuous review of system events through logged information is important as this one of the main purposes for logs securely collected. Logs provide great insights into the behaviour of the operating system and observing that behaviour is important. There are multiple strategies which a Cybersecurity Architect / Administrator / Manager may employ to perform this task; It may be achieved by manual processes, which is quite an effort-intensive job or it may be achieved by a solution like SIEMs (Security information and event management) and Syslog solutions.

Additional Important Countermeasures

System Integrity Checks, Antivirus & Anti Malware, Advance Persistence Threat Protection, Data loss prevention (DLP), Hoste Based Intrusion Prevention System, Third-Party Authentication, Authorization & Accounting Solution, Establishing and Maintaining information security policies for operating systems, Enterprise Monitoring Tools etc.

Testing Operating System Implementation and Operation:

Maintaining a software or operating system in a secure state is a continuous process and testing security posture on a regular basis (Daily, Weekly, Monthly etc. Depends upon risk rating) is very essential. Security testing is covered under a dedicated section though let’s understand some testing methodology applicable for software like operating systems.

Vulnerability Assessment:

Vulnerability assessment is testing which identifies vulnerabilities and weakness of a system to determine how that system can be exploited by an attacker or malicious user. If we see vulnerability assessment as a process than we may be added that a process which identifying, classifying and prioritizing vulnerabilities and provide the necessary knowledge, awareness and risk background to understand the threats. The vulnerability assessment process typically performed using automated tools and manual methods. There are a variety of methods are used for vulnerability assessment though specific to the operating system a host-based scan typically include below:

• Patch Testing or Patch Audit or Scanning Missing Patchs
• Port Scanning
• Service Scanning and service enumeration
• Scanning the software, applications on the Operating System
• Configuration Assessment of Operating System and Software on it
• Scanning known Vulnerabilities of Operating System and Software on it
• Scanning for Virus, Malware and Malicious software
• Scan information disclosure by Operating system
• Etc.

Vulnerability Assessment and Penetration Testing is a very vast area to understand by a security professional. Hence, very limited aspects specific to the operating system are touched here, will add a dedicated section on security testing on this website and provide a link here.

Penetration Testing:

Penetration testing is a methodological approach to security assessment that includes the vulnerability assessment and demonstrates if the vulnerabilities in the system can be successfully exploited by attackers. Penetration testing is a method of evaluating the security of a system by simulating an attack on the system to find out the vulnerabilities and weakness in the system that could be exploited by an attacker or malicious user. Penetration testing not only identifies weakness or vulnerability in the system also identifies how it can be exploited by an attacker. This provides great insights to Cybersecurity Architect / Administrator / Manager to plan correct countermeasures. Below is the type of penetration testing:

• Black Box: In this type of penetration testing a pentester (security assessor performing Penetration Testing) have no prior technical knowledge of the system to be tested.
• Grey Box: In this type of penetration testing a pentester (security assessor performing Penetration Testing) have Limited technical knowledge of the system to be tested.
• White Box: In this type of penetration testing a pentester (security assessor performing Penetration Testing) have complete technical knowledge of the system to be tested.