The document outlines vulnerabilities in information systems, defining vulnerability as flaws that compromise the system's security. It discusses various authentication methods, secure coding practices, and emphasizes the importance of threat modeling in identifying and mitigating risks. Additionally, it highlights the steps necessary to rectify software vulnerabilities and the role of security tools in protecting against attacks.

1. Cyber Security
Prepared By: Ms Kashf Ul Huda

2. Chap#1: Vulnerabilities in Information System
Recommended Book: Cyberspace and Cybersecurity

3. What is vulnerability?
• Vulnerability in any system is the result of an intentional or
unintentional omission or of an inadvertent design mistake that
directly or indirectly leads to a compromise in the system’s
availability, integrity, or confidentiality.
• Hidden in
• Information access security
• Computer and storage security
• Communication security
• Operational and physical security

4. What is vulnerability?
• Components of information system
• People
• hardware
• Software
• Reliability vs vulnerability
• Quantify the abstract concept of vulnerability
• The aim is to express the perceived level of security in a way that is
measurable, standardized, and understood and to improve “the
measurability of security through enumerating baseline security data,
providing standardized languages as means for accurately communicating
the information, and encouraging the sharing of the information with users
by developing repositories

5. Authentication
• Vulnerabilities can be hidden in data, code, and most often in
processes that inadvertently allow unauthorized access
• Security at both user and server end.
• User end authentication:
• OTP
• Biometrics
• Questionnaires
• User device identification numbers (MAC, IMEI, manufacturer’s serial
number)

6. MAC

7. International Mobile Equipment Identity
(IMEI)

8. Authentication
• Server-side authentication:
• Certificates
• IP restrictions
• Data encapsulations
• Data in transit
• Hash codes (CRC)
• Private/ Pubic key encryption mechanism

9. When vulnerabilities originate?
• Firewall penetration
• Trojan horse attack
• Decentralization
• Static resource allocation
• During system upgradation
• Being adapted to new environment

10. Measuring Vulnerabilities
• Security Content Automation Protocol (SCAP)
• Used for standardization classification and assessment of security
content in software sysetms.
• Standardize the way security vulnerability and configuration
information is identified and catalogued.
• Developed by NIST

11. Components of SCAP
• Common vulnerabilities and exposure (CVE)
• Common configuration and enumerator (CCE)
• Common platform enumerator (CPE)
• Common vulnerability scoring system (CVSS)
• Extensible configuration checklist description format (XCCDF)
• Open vulnerability and assessment language (OVAL)
Note: the above standards comprise a very powerful infrastructure for
information system vulnerability assessment and reporting.

12. Components of SCAP

13. Additional Components of SCAP

14. Avoiding vulnerabilities through Secure
Coding
• Old programming culture
• Minimum number of lines
• Executable in a minimum amount of time
• Memory and processor time were valuable assets
• Fault tolerance for data integrity.
• No extra code for security as system were stand-alone and physically isolated.
• Neither memory space nor processing speed seem to be the
programming constraint anymore.
• High speed total interconnectivity

15. Avoiding vulnerabilities through Secure
Coding
• vulnerabilities can be minimized by segmenting the code and the data
into resident and transient sections.
• Call the data and application only that is needed rather than bringing
the entire inventory of application.
• Minimize the impact of malware intrusion.
• Experts openly say: “The Internet is a hostile environment, so
you must . . . [be able to] withstand attack[s to survive,” and it is often
referred to as the Wild Wild Web, WWW.

16. Avoiding vulnerabilities through Secure
Coding
• Design web with security from hostile attacks
• Move from minimal code to minimal vulnerability.
• Concepts of s/w quality and s/w security have been embedded.
• Spend time in designing secure apps than costly development patches
and bad publicity etc.
• An increasing trend is for web applications to come with their own
firewalls rather than exclusively relying on those of the hosting
system.

17. Avoiding vulnerabilities through Secure
Coding
• Cost of fixing vulnerability
• Very high from five to seven digit dollar
• Depend on how deep in design the vulnerability exists.
• During the fixing, resources will have to be
taken away from other assignments to attend to this matter in a very
urgent way.

18. Steps necessary to rectify a software
vulnerability

19. Steps necessary to rectify a software
vulnerability
1. Location of the origin of the vulnerability
2. Design of a patch that will strengthen the code and eliminate the
vulnerability
3. Application and testing of the patch
4. Confirmation that there are no side effects
5. Drafting of patch documentation
6. Preparation of a patch distribution plan to all affected clients
7. Patch installation
8. Confirmation of the effectiveness of the patch; public relations
campaign to offset prior negative publicity

20. Most frequent vulnerabilities
• Buffer overflow
• Arithmetic overflow
• Format string attacks
• Command injections
• Cross-site scripting (XSS)
• SQL injections
• Insecure direct object reference

21. Most frequent vulnerabilities
• Insecure storage
• Weak cryptography
• Race conditions

22. Avoiding vulnerabilities through Secure
Coding
• the software designer’s mindset must have two parallel tracks
• functionality and security
• with security being a mechanism that reveals and subsequently blocks
intrusions.
• Such security mechanism should be robust and well designed and should
never be replaced by some data obscurity scheme that attempts to outsmart
the attacker.
• The designer must also think of the user convenience and provide a security
mechanism that poses no hindrance to the normal operations, being as
transparent to the user as possible.

23. Mistakes can be good
• Learn from mistakes.
• Making a mistake again and again is foolish.
• Assign privilege to the extent where it is needed.
• Make list of resources and their permissions (read, write, execute, create ,
delete) at the time of installation.
• This way, should a malware install itself in the application, the potential
damage will be minimal, and the malware will not be able to roam inside
the system
• when a computer is a single user, it should not necessarily operate in
the administrator mode, but in the user mode.

24. Threat Classification
• Any circumstance or event that can negatively impact assets
• Basic types of threats
• Illegal data change
• Illegal data access
• Illegal obstruction of data access
Information security researchers at Microsoft broadly classified all
threats in six categories named as “STRIDE”

25. Table 1.1 Information system Threats

26. Table 1.1 Information system Threats

27. Threat Modeling Process
1.Define what constitutes the information system in question. That is,
determine the functional and geographical borders of what we refer to
as being our system. Beyond what point is it not our responsibility or
liability?
2. Now that we have quantified our system, we attempt to identify
what we consider as being the threats that are based on internal or
external vulnerabilities. The STRIDE categories, mentioned previously,
can serve as a starting point to threats classification.

28. Threat Modeling Process
3. Recognize which of the threats, in your context of operations, constitute
absolute danger that may lead to a catastrophic impact on the system.
Define the modes under which such threats can become successful attacks.
4. Develop defense options for each and every recognized threat, and rank
the considered defense mechanisms based on effectiveness and demand of
resources.
5. Select optimum approaches to threat eliminations, balancing
effectiveness, probability of occurrence, severity of occurrence, and solution
development cost.

29. Threat Modeling Process
• Iterative process
• Participants

30. Security starts at Home
• home is the creative phases of the Software Development Life Cycle
(SDLC), especially the program design and coding stages.
• From abstract needs to formal requirements—Analysis (security
requirements are defined)
2. From formal requirements to overall design—Design (Security
mechanisms are developed)
3. From overall design to program code
4. From all of the above to documentation drafting
5. From all of the above to system testing (Vulnerabilities are
discovered and eliminated)
6. From system testing to system utilization (or to a previous step)
7. From system utilization to needs enhancement (Step 1)

31. Security starts at Home
• Measures taken to improve s/w development process
• Programmers certification in secure coding
• Software certification as to secure coding
• Utilization of software analysis tools
• Measures taken in intra-organizational s/w development initiatives
• Programmers certification in secure coding
• Software certification as to secure coding
• Utilization of software analysis tools

32. Tools for Security
• Categories of S/w tools
• Code Coverage—Keeps track of the code and data locations that have been
created, read, or modified.
◾ Instruction Trace—Records the execution of each instruction, making it
available for subsequent step-by-step analysis.
◾ Memory Analysis—Keeps track of the memory space utilization, looking for
possible violations.
◾ Performance Analysis—Based on the user’s criteria, software are analyzed
and fine-tuned for performance optimization.

33. Security in Application
• Vulnerabilities come with insecure application.
• MS Office 2003 is the example.
• Vulnerability Notes Database
• Severity Metric
• A most common gateway to malware attacks is the web browser.
• Many web browsers are configured to provide increased functionality
at the cost of decreased security.”