Research on Different Cyber Security Standards

10 min readJan 3, 2022

Hello guys👋👋 ,Prajit here from the BUG XS Team and Cyber Sapiens United LLP Cybersecurity and Red Team Intern, in this I am regularly given some interesting tasks, In my fourth task, I was given to research on different cybersecurity standards, which are very important from industrial point of view.

Part-A: OWASP ASVS

The OWASP Application Security Verification Standard (ASVS) provides a basis for testing web application technical security controls and also provides developers with a list of requirements for secure development. In this there are 286 controls and 14 verification topics.

The latest version of ASVS is 4.03, and it has two main goals

1. To help the organizations develop and maintain secure application.

2. To allow security service vendors, security tools vendors and consumers to align their requirements and offerings.

The ASVS defines the three security verification levels, with each increasing depth.

1. Level-1 : ASVS Level 1 is for low assurance levels, and is completely penetration testable

Level 1 is the bare minimum that all applications should strive for. It is also useful as a first step in a multiphase effort or when applications do not store or handle sensitive data and therefore do not need the more rigorous controls of Level 2 or 3.

Level 1 controls can be checked either automatically by tools or simply manually without access to source code.

An application achieves ASVS Level 1 if it adequately defends against application security vulnerabilities that are easy to discover, and included in the OWASP Top 10 and other similar checklists.

Threats to the application will most likely be from attackers who are using simple and low effort techniques to identify easy-to-find and easy-to-exploit vulnerabilities. This is in contrast to a determined attacker who will spend focused energy to specifically target the application, hence if data processed by your application has high value, you would rarely want to stop at a Level 1 review.

2. Level-2 : ASVS Level 2 is for applications that contain sensitive data, which requires protection and is the recommended level for most apps.

Level 2 ensures that security controls are in place, effective, and used within the application. Level 2 is typically appropriate for applications that handle significant business-to-business transactions, including those that process healthcare information, implement business-critical or sensitive functions, or process other sensitive assets, or industries where integrity is a critical facet to protect their business, such as the game industry to thwart cheaters and game hacks.

An application achieves ASVS Level 2 (or Standard) if it adequately defends against most of the risks associated with software today.

Threats to Level 2 applications will typically be skilled and motivated attackers focusing on specific targets using tools and techniques that are highly practiced and effective at discovering and exploiting weaknesses within applications.

3. Level-3 : ASVS Level 3 is for the most critical applications — applications that perform high value transactions, contain sensitive medical data, or any application that requires the highest level of trust.

ASVS Level 3 is the highest level of verification within the ASVS. This level is typically reserved for applications that require significant levels of security verification, such as those that may be found within areas of military, health and safety, critical infrastructure, etc.

An application at ASVS Level 3 requires more in depth analysis of architecture, coding, and testing than all the other levels.

A secure application is modularized in a meaningful way (to facilitate resiliency, scalability, and most of all, layers of security), and each module (separated by network connection and/or physical instance) takes care of its own security responsibilities (defense in depth), that need to be properly documented. Responsibilities include controls for ensuring confidentiality (e.g. encryption), integrity (e.g. transactions, input validation), availability (e.g. handling load gracefully), authentication (including between systems), authorization, and auditing (logging).

An application achieves ASVS Level 3 (or Advanced) if it

adequately defends against advanced application security vulnerabilities and also demonstrates principles of

good security design.

OWASP, as a vendor-neutral not-for-profit organization, does not currently certify any vendors, verifiers or software hence all such assurance assertions, trust marks, or certifications are not officially vetted, registered, or certified by OWASP, so an organization relying upon such a view needs to be cautious of the trust placed in any third party or trust mark claiming ASVS certification.

Part-B: OSSTMM

Open Source Security Testing Methodology Manual (OSSTMM) is a peer reviewed methodology for performing security tests and metrics and maintained by the Institute for Security and Open Methodologies (ISECOM).

Although the OSSTMM provides a methodology to perform penetration tests, it is foremost an auditing methodology that can satisfy regulatory and industry requirements when used against corporate assets.

OSSTMM rules of engagement are very comprehensive and an important part of the methodology. OSSTMM recommends a set of activities/guidelines in producing the documents covering the following, at the beginning of a pentesting project -

1. Project scope

2. Confidentiality and non-disclosure assurance

3. Emergency contact information

4. Statement of work change process

5. Test plan

6. Test process

7. Reporting standards

The OSSTMM provides guidance on how to test the operational security of five channels so organizations can understand the full extent of their security and determine how well their security processes actually function. It’s about what your operations actually do, and not just what they are supposed to do. There are 5 testing channel and methodology.

1. Human Security: focuses on assessing personnel security awareness levels and the effectiveness of the security training in the organisation. The methods discussed revolve around social engineering attacks and assessing the level of exposure of sensitive information about the organisation and its employees.

2. Physical Security: Assesses access controls, security processes and physical locations such as buildings, perimeters and military bases.

3. Wireless Communications: Covers different forms of wireless which can be intercepted or disrupted, including Wi-Fi networks, RFID and so on. Electronic communications, signals, and emanations are all considered wireless communications that are part of the operational security testing.

4. Telecommunications: Covers the different communication channels in the organisation, including VoIP, PBX and voicemail. Whether the telecommunication network is digital or analog, any communication conducted over telephone or network lines are tested in the OSSTMM

5. Data Networks: The security testing of data networks includes electronic systems and data networks that are used for communication or interaction via cable and wired network lines. This channel focuses describes the following activities:

❖ Network surveying

❖ Identification

❖ Access process

❖ Service identification

❖ Authentication

❖ Spoofing

❖ Phishing

❖ Resource abuse

OSSTMM uses the concept of modules, defining them as a set of processes or phases which are applicable for each channel. The modules are described at the relatively high level and the implementation of each module in the different channels will be specific to the actual domain, technical and regulatory constraints. There are four modules in this.

Phase I: Regulatory

Posture review — review relevant regulatory and legislative frameworks and standards.

Logistics — identify any physical and technical constraints to the processes in the channel.

Active detection verification — evaluate interaction detection and response.

Phase II: Definitions

Visibility audit — assess the visibility of information, systems and processes relevant to the target.

Access verification — assess access points to the target

Trust verification — assess trust relationship between the systems (or between people)

Control verification — assess controls to maintain confidentiality, integrity, privacy and non-repudiation within the systems

Phase III: Information phase

Process verification — review the security processes of the organisation.

Configuration verification — evaluate the processes under various security level conditions.

Property validation — examine the physical or intellectual property available at the organisation.

Segregation review — determine the levels of personal information leaks.

Exposure review — evaluate sensitive information exposure.

Competitive intelligence — determine information leaks which could aid competitors.

Phase IV: Interactive controls test phase

Quarantive verification — evaluate the effectiveness of quarantine functions on the target.

Privileges audit — review effectiveness of authorisation and potential impact of unauthorised privilege escalation.

Survivability validation — assess systems resilience and recovery.

Alerts and logs review — review audit activities in ensuring reliable events trail.

OSSTMM focuses on which items need to be tested, what to do before, during and after a security test, and how to measure the results. One particularly useful part of OSSTMM is that it has a section covering international best practices, laws, regulations and ethical standards.

Part-C : PTES

The Penetration Testing Execution Standard(PTES), is a standard that was developed and continues to be enhanced by a group of information security experts from various industries. PTES provides a minimum baseline for what is required of a penetration test, expanding from initial communication between client and tester to what a report includes.

The goal of PTES is to provide quality guidance that helps raise the bar of quality for penetration testing. The standardization of penetration testing procedures helps organizations better understand the services they are paying for and gives penetration testers accurate direction on what to do during a penetration test.

There are 7 stages of PTES:

1. Pre-engagement Interactions: This is the preparation phase for the pen test. It is all about document approvals and tools needed for the test.

Penetration testers will prepare and gather the required tools, OS, and software to begin the penetration test.

2. Intelligence gathering: In this phase information about the target system are gathered from external sources like social media websites, official records etc. This phase comes under OSINT (Open-Source Intelligence). This step is especially valuable in network penetration testing.

3. Threat Modelling: It is a procedure for optimizing network security by identifying objectives and vulnerabilities, and then defining countermeasures to prevent, or mitigate the effects of, threats to the system. It is skipped in typical pentests. PTES focuses on business assets, business processes, threat communities, and their capabilities as key elements of threat modeling.

4. Vulnerability Analysis: Penetration testers are expected to identify, validate, and evaluate the security risks posed by vulnerabilities. This analysis of vulnerabilities aims to find flaws in an organization’s systems that could be abused by a malicious individual.

5. Exploitation: In this phase, the tester tries to reach the security of the target system using the vulnerabilities previously identified and validated.

6. Post Exploitation: This phase maintains control over the target system and collects data. The penetration tester must consider the value of the compromised machine and its usefulness in further compromising the network.

7. Reporting: An executive-level and technical-level report will be delivered covering what was tested, how it was tested, what vulnerabilities were found, and how the penetration tester found those weaknesses. The report should provide your organization with helpful guidance on how to better your information security practices.

Part-D : SANS

● SANS stands for SysAdmin, Audit, Network, and Security. They’re a private organization that, per their self description, is “a cooperative research and education organization”. The sole focus of this organisation is security, and they’ve become an industry standard framework for incident response.

● The SANS Incident Response Process consists of 6 steps.

Step 1) Preparation — In this step you compile a list of all your assets, including but not limited to: servers, networks, applications, and critical endpoints (like C-level laptops). After you’ve compiled your asset list, rank them by level of importance. Then monitor their traffic patterns so you can create baselines to be used for comparisons later.

Create a communication plan, with guidance on who to contact, how, and when based on each incident type. Don’t forget to get buy-in from everyone on this contact list to prevent hiccups or finger pointing later.

Determine which security events, and at what thresholds, these events should be investigated.

Then create an incident response plan for each type of incident. It can be improved through security event simulations, where you identify holes in your process, but it will also be improved after actual events (more on that later). The point is, get a process in place.

Step 2) Identification — At this point in the process, a security incident has been identified. This is where you go into research mode. Gather everything you can on the incident. Then analyze it. Determine the entry point and the breadth of the breach. This process is made substantially easier and faster if you’ve got all your security tools filtering into a single location.

Step 3) Commitment — Containment aims to stop the bleeding. Here is where you patch the threat’s entry point.

Step 4) Eradication — Eradication aims to remove the threat. If the threat gained entry from one system and proliferated into other systems, you’ll have more work on your hands here.

Step 5) Recovery — Recovery aims to get the system operational if it went down or simply back to business as usual if it didn’t.

Step 6) Lessons Learned — This step provides the opportunity to learn from your experience so you can better respond to future security events. Tempting as it may be to skip, with your never ending to-do list, this step is strongly recommended. Take a look at the incident with a humble but critical eye to identify areas for improvement. Then go add those improvements to your documentation.

➔ Most Effective: According to me OWASP ASVS is the most effective security standard that industries should follow, because that consist of guidelines from prevention of cyber attack to what to do in case of cyber attack. Also one by one on each level it keeps on eliminating different sets of vulnerability making the application more secure. Also depending on what type website you are running you can pick the level and get that level of security accordingly.