0% found this document useful (0 votes)
144 views60 pages

EMCS-602: Cybersecurity Policies & Issues

This document summarizes a lecture on access control fundamentals for an executive cybersecurity master's program. The lecture covers security postures, identity verification through identification, authentication and authorization. It discusses concepts like principle of least privilege and need-to-know access controls. The objectives are to recognize policies to support access control, system acquisition, development and maintenance.

Uploaded by

amna zia
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
144 views60 pages

EMCS-602: Cybersecurity Policies & Issues

This document summarizes a lecture on access control fundamentals for an executive cybersecurity master's program. The lecture covers security postures, identity verification through identification, authentication and authorization. It discusses concepts like principle of least privilege and need-to-know access controls. The objectives are to recognize policies to support access control, system acquisition, development and maintenance.

Uploaded by

amna zia
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 60

Week (#4) Session (#1)

Computer science Department


Executive Master in Cyber Security

Cybersecurity Policies
& Issues
EMCS-602

Access Control
Management and
“Security Program and Policies“, System Security
Requirements
by Omar Santos

Spring2021
2020-2021
Focus of This Session
Break Systems development lifecycle (SDLC)
Authorization
&
Authentication Secure code
Access Control

Monitoring

his Week Objectives:


➢ Recognize policies to support access control, system acquisition, development, and
maintenance.
Week (5) Session (1) 2
Outline
What Is a Security Posture?

How is Identity Verified?

Authorization and Accounting

User Access Controls

Systems Development Life Cycle (SDLC)

Commercially Available or Open Source Software

The Testing Environment

Secure Code

The Open Web Application Security Project

Importance of Broken Authentication and Session Management


3
Week (4) Session (1)
Questions from previous lecture
▪ Which of the following data types includes details a bout a file or document?
A. Apparent data
B. Hidden data
C. Metadata
D. Cash data
▪ Confidential data can reside on which of the following items?
A. Smartphones
B. Cameras
C. Scanners
D. All of the above
▪ It is very common that organizations use threat intelligence to
A. maintain competitive advantage
B. configure their antivirus to be less invasive
C. hire new employees for their cybersecurity teams
D. better know how threat actors carry out their attacks and to gain insights about the
current threat landscape
▪ In its native form, email is transmitted in _________.
A. cipher text B. clear text C. hypertext D. meta text

4
Week (4) Session (1)
Computer science Department
Executive Master in Cyber Security

Source of Slides and Refs:


Developing Cybersecurity
Programs and Policies, by
Omar Santos, 3rd Edition

Access Control
Fundamentals
Access Control Fundamentals

▪ Access controls
▪ are Security features that govern how users and processes
communicate and interact with systems and resources
▪ Primary objective is to protect information and systems from
CIA
Unauthorized Access Modification Disruption
Confidentiality Integrity Availability

▪ Identity Management
▪ process for identifying, authenticating and authorizing users or
groups of users to have access to applications, systems or
networks
6
Week (4) Session (1)
Access Control Fundamentals
▪ Three common attributes of access controls
Identification Scheme
• Used to identify unique records in a set, such as a username.
• Identification is the process of the subject supplying an identifier to the object.

Authentication Method
• How identification is proven to be genuine.
• Authentication is the process of the subject supplying verifiable credentials to the object.

Authorization Method
• How access rights and permission are granted.
• Authorization is the process of assigning authenticated subjects the permission to carry
out a specific operation.
7
Week (4) Session (1)
Access Control Fundamentals
What Is a Security Posture?

▪ Two fundamental security postures:


▪ Open, which implements the “default allow” model
▪ means that access not explicitly forbidden is permitted.
▪ Secure, which implements the “default deny” model
▪ means that access not explicitly permitted is forbidden.

▪ Every access control decision for a company is based on


that company’s security posture

▪ Microsoft (default allow→ default deny).

8
Week (4) Session (1)
Access Control Fundamentals
What Is a Security Posture? Cont.
▪ Principle of Least Privilege
▪ States that all users—whether they are individual contributors, managers,
directors, or executives—should be granted only the level of privilege they need
to do their jobs, and no more.
▪ The same concept of principle of least privilege can be applied to software.
▪ This is a strong foundation for any access control policy.
▪ Protects the data but also protects users. They can’t be accused of having
deleted a file to which they can’t gain access!
▪ Separation of duties is an administrative control that dictates that a single
individual should not perform all critical- or privileged-level duties
▪ From a cultural stand point, it is important to explain to employees why they
are not “trusted” with all the company’s data.
▪ Example:
▪ Security auditors
▪ Network administration and logs
▪ Software developers 9
Week (4) Session (1)
Access Control Fundamentals
What Is a Security Posture? Cont.
▪ Need-to-know
▪ Definition: Having a demonstrated and authorized reason for
being granted access to information
▪ Should be made a part of the company’s culture
▪ Should be incorporated in security training curriculum
▪ At the least protects the confidentiality of corporate data,
but may also protect integrity and availability depending on
the attack type

10
Week (4) Session (1)
Access Control Fundamentals
How is Identity Verified?
▪ Identification is the process of providing the identity
of a subject or user.
▪ First step to granting access (authentication, authorization, and
accounting process) is user identification

▪ The key concepts of identification.


▪ Identities should be unique.
▪ Identities should be non descriptive.
▪ Identities should be securely issued.
▪ Identities can be location-based.

11
Week (4) Session (1)
Access Control Fundamentals
How is Identity Verified? Cont.

12
Week (4) Session (1)
Access Control Fundamentals
What Is Authorization?
▪ The process of assigning authenticated subjects
permission to carry out a specific operation
▪ The authorization model defines how access rights and
permission are granted.

▪ Three primary authorization models


▪ Object capability
▪ Used programmatically and based on a combination of a unforgettable
reference and an operational message
▪ Security labels
▪ Mandatory access controls embedded in object and subject properties
▪ Access Control Lists
▪ Used to determine access based on some criteria
13
Week (4) Session (1)
Access Control Authorization Policy

14
Week (4) Session (1)
Access Control Fundamentals
Accounting

▪ The process of auditing and monitoring what a user


does once a specific resource is accessed.

▪ Help during detection and investigation of


cybersecurity breaches.
▪ What the user did with that resource?
▪ When the user stopped using the resource?

15
Week (4) Session (1)
Authentication Policy

16
Week (4) Session (1)
Computer science Department
Executive Master in Cyber Security

In-Class
Activities

Web Project-1

Have I been
pwned?
Computer science Department
Executive Master in Cyber Security

Source of Slides and Refs:


Developing Cybersecurity
Programs and Policies, by
Omar Santos, 3rd Edition

User Access Controls


User Access Controls
Why Manage User Access?
▪ Maintain confidentiality and data integrity.
▪ Used to ensure authorized users can access information and
resources while unauthorized users cannot access information
and resources
▪ Users should have access only to information they need to do
their job and no more
▪ All administrative or privileged account activity should be logged
and reviewed.
▪ Mitigating controls
▪ Segregation of duties
▪ tasks be assigned to individuals in such a manner that no one individual
can control a process from start to finish.
▪ Dual control
▪ two individuals must both complete their half of a specific task.
19
Week (4) Session (1)
User Access Controls
Why Manage User Access?
▪ Administrative accounts should be used only when the activity
being performed requires elevated rights and permissions.
▪ There is no need to use this type of account to perform routine
activities such as checking email, writing reports, performing
research on the Internet, and other activities for which a basic
user account will suffice.
▪ This is important because viruses, worms, and other malicious code will
run in the security context of the logged-in user.

20
Week (4) Session (1)
User Access Controls
Why Mange User Access? Cont.

▪ User Account Controls in


Windows
▪ Microsoft Windows User
Account Control (UAC) can be
configured so that
applications and tasks always
run in the security context of
a non-administrator account,
unless an administrator
specifically authorizes
administrator-level access to
the system. Microsoft takes
this to the next level since
Windows 10. Logon Process
21
Week (4) Session (1)
User Access Controls
Why Mange User Access? Cont.

▪ User Account Controls in Windows Cont.

The Consent Prompt

The Credential Prompt


22
Week (4) Session (1)
User Access Controls
Why Mange User Access?
▪ User Account Controls in Linux
▪ There are two ways to run administrative applications
▪ The super user (root) with the su command
▪ Sudo tool → enables a user to have administration privileges without
logging in directly as root.
▪ For example, to be able to install an application in Debian or Ubuntu
you can run the sudo apt-get install command followed by the
application or package name that you would like to install.

23
Week (4) Session (1)
User Access Control and Authorization Policy

24
Week (4) Session (1)
Administrative and Privileged Account Policy

25
Week (4) Session (1)
User Access Controls
What Types of Access Should Be Monitored?
▪ Three main monitoring areas:

Successful Privileged
Failed access
access operations

Unauthorized attempts
• whether an intruder is “testing” Critical and unfettered
A record of user activity
the system or has launched an access
attack

Authorized user issues Compromise or misuse


date, time, and action of administrator
(such as, authenticate, • if users are having problems accounts can have
logging in, accessing
read, delete, or modify) disastrous
information, or doing their jobs
consequences
26
Week (4) Session (1)
User Access Controls
Is Monitoring Legal?

▪ Employees should have no expectation of privacy while


on company time or when using company resources

▪ Courts have favored an employer’s right to protect


their interests over individual privacy rights because:
▪ The work is done at the employer’s place of business.
▪ The employer owns the equipment.
▪ The employer has an interest in monitoring employee activity to ensure
the quality of work.
▪ The employer has the right to protect property from theft and fraud.

27
Week (4) Session (1)
User Access Controls
Is Monitoring Legal? Cont.
▪ Courts indicate that monitoring is acceptable if it is
reasonable:
▪ Justifiable if serving a business purpose
▪ Policies are set forth to define what privacy employees should
expect while on company premises
▪ Employees are made aware of what monitoring means are
deployed
▪ Acceptable use agreement should include a clause
informing users that the company will and does monitor
system activity
▪ Users must agree to company policies when logging on

28
Week (4) Session (1)
Monitoring System Access and Use Policy

29
Week (4) Session (1)
Computer science Department
Executive Master in Cyber Security

In-Class
Activities

Discussion Questions
& Web Projects
Discussion Questions
▪ Discussion Question 1
▪ What makes a password secure?

▪ Discussion Question 2
▪ Remember the passwords is against good security practices !
As the system administrator for a medium-sized company, how
would you convince users that letting the computer operating
system or browser application remember their passwords is
against good security practices?

31
Week (4) Session (1)
Web Projects
▪ Web project-1 (Watch, Read-1, Read-2 and Make an
argument )
▪ Make an argument for either single-factor or multiple-factor authentication in the
workplace.
▪ Visit https://youtu.be/10-DOckz5A8,
▪ http://www.cnet.com/news/two-factor-authentication-what-you-need-to-know-
faq/
▪ http://en.wikipedia.org/wiki/Strong_authentication for additional information
to help you make your arguments. Consider cost, efficiency, and user
compliance.
▪ Web project-2 (Explore the user access control settings)
▪ On any Windows computer, explore the user access control settings from the
control panel. Use this link for more information on the User Account Control
works https://docs.microsoft.com/en-us/windows/security/identity-
protection/user-account-control/how-user-account-control-works
▪ Present your findings to the class.
32
Week (4) Session (1)
Computer science Department
Executive Master in Cyber Security

Homework

Case Study

Facebook and
A Privacy Breach
Facebook and A Privacy Breach
▪ Assessing a Current Security Breach
▪ It often feels like every week there is a major breach. In early 2018 Facebook
suffered from
▪ a privacy breach. Research this incident and answer the following questions:
▪ 1. How did the Facebook breach happen? How did it impact its reputation?
▪ 2. Research another breach that is more current. How does it compare to the
Facebook
▪ breach?
▪ 3. Why was the attack successful? What controls were missing that may have
prevented or
▪ detected the attack?
▪ 4. How much did the breach cost each company?

▪ https://www.nytimes.com/2018/09/28/technology/facebook-hack-data-breach.html

34
Week (4) Session (1)
We will come back
After (5) minutes

35
Week (4) Session (1)
Computer science Department
Executive Master in Cyber Security

Source of Slides and Refs:


Developing Cybersecurity
Programs and Policies, by
Omar Santos, 3rd Edition

System Security
Requirements
System Security Requirements
▪ Security must be taken into account from the genesis
of the project
▪ Security should be a priority objective during the
design and acquisition phases of any new information
system, application, or code development.
▪ Retroactively attempting to inject security back into existing code usually
either does not work or ends up creating new vulnerabilities and/or
instability in the code
▪ Utilizing a structured development process increases the probability that
security objectives will be achieved.

37
Week (4) Session (1)
System Security Requirements
What Is SDLC?
▪ Systems development lifecycle (SDLC) provides a standardized
process for all phases of any system development or acquisition
effort.
▪ There are five phases in the SDLC according to NIST
Operational/
Development
Initiation Maintenance
/acquisition phase
phase Disposal
phase Implementatio
phase
n phase
• Establishes
• The system • The
the need for • The system is • Ensure the
is designed, tested and system in
a system and orderly
purchased, retested, and put into
documents terminatio
programed, any production
its purpose n of the
or modifications
are applied until
sys
developed
it is accepted
38
Week (4) Session (1)
System Security Requirements
What Is SDLC? Cont.
▪ Initiation phase
▪ The organization establishes the need for a system and
documents its purpose
▪ Security planning must begin
▪ All stakeholders have a common understanding of the
security considerations
▪ Other tasks include assignment of roles and responsibilities,
identification of compliance requirements, decisions on
security metrics and testing, and the systems acceptance
process

39
Week (4) Session (1)
System Security Requirements
What Is SDLC? Cont.
▪ Development/acquisition phase
▪ The system is designed, purchased, programmed, developed,
or otherwise constructed
▪ Conducting a risk assessment
▪ Analyze security requirements, perform functional and
security testing, and design the security architecture
▪ The aim is to identify potential risks associated with the
project and to use this information to select baseline
security controls

40
Week (4) Session (1)
System Security Requirements
What Is SDLC? Cont.
▪ Implementation/Assessment phase
▪ The organization configures and enables system security
features, tests the functionality of these features, installs
or implements the system, and obtains a formal authorization
to operate the system.
▪ Design reviews and system tests should be performed before
placing the system into operation to ensure that it meets all
required security specifications.
▪ Authorization
▪ It is the responsibility of the system owner or designee to green light
the implementation and allow the system to be placed in production
mode.

41
Week (4) Session (1)
System Security Requirements
What Is SDLC? Cont.
▪ Operational/Maintenance phase
▪ Systems and products are in place and operating,
enhancements and/or modifications to the system are
developed and tested, and hardware and software
components are added or replaced
▪ Configuration management and change control processes to
ensure that required security controls are maintained
▪ Continuously monitor performance of the system
▪ Periodic testing and evaluation of the security controls in an
information system must be conducted to ensure continued
effectiveness and to identify any new vulnerabilities that may
have been introduced or recently discovered

42
Week (4) Session (1)
System Security Requirements
What Is SDLC? Cont.
▪ Disposal phase
▪ Systems normally evolve or transition to the next generation
because of changing requirements or improvements in technology.
▪ System security plans should continually evolve with the system.
▪ Much of the environmental, management, and operational
information for the original system should still be relevant and
useful when the organization develops the security plan for the
follow-on system.
▪ Disposal activities archiving information, sanitization of media,
and disposal of hardware components must be done in accordance
with the organization’s destruction and disposal requirements and
policies

43
Week (4) Session (1)
System Security Requirements
Systems Development Life Cycle (SDLC) Policy

44
Week (4) Session (1)
System Security Requirements
What About Commercially Available or Open Source
Software?
▪ SDLC principles apply to commercial off-the-shelf
software (COTS) and open source software
▪ Development is not done in-house but should be evaluated to
ensure it meets or exceeds the organization’s security
requirement
▪ Only stable and tested software should be deployed on
production serves to protect data availability and data
integrity.

45
Week (4) Session (1)
System Security Requirements
What About Open Source Software? Cont.
▪ Software Releases
Alpha Phase
Initial release of software for testing can be unstable and can cause crashes or
data loss

Beta Phase
Indicates that the software is complete and ready for usability testing

Release Candidate (RC)


Hybrid of beta and final release version has the potential of being final release unless
significant issues are identified

General Availability or Go Live


Week (4) Session (1) Software has been made commercially available 46
System Security Requirements
What About Open Source Software? Cont.

▪ Software Updates
▪ Updates are different from security patches
▪ Security patches are designed to address a specific vulnerability
and are applied in accordance with the patch management policy
▪ Updates include functional enhancements and new features
▪ Updates should be thoroughly tested before implemented
▪ A documented rollback strategy should exists before applying
any updates
▪ If update required a system reboot, it should be delayed until
the reboot has the least impact on business operations

47
Week (4) Session (1)
System Security Requirements
The Testing Environment

▪ Testing Environment Concerns


▪ Companies SHOULD have a test environment
▪ The closer to the live environment the test environment is,
the more expensive it is, but the more accurate the testing
will be
▪ A cost/ benefit analysis that takes into consideration the
probability and associated costs of downtime, data loss, and
integrity loss will determine how much should be invested in a
test or staging environment.

48
Week (4) Session (1)
System Security Requirements
The Testing Environment Cont.
▪ Protecting Test Data
▪ Testing environment should be 100% segregated from the live
network
▪ Live data should NEVER be used in a test environment
▪ The test servers may not be as well secured as the live,
production servers
▪ Medical practice with an electronic medical records (EMR) database
example
▪ De-identified or dummy data should be used in place of live
data
▪ De-identification is the process of removing information that would
identify the source or subject of the data.
▪ Dummy data is, in essence, fictional. For example, rather than using
actual patient data to test an EMR database, the medical practice
would enter fake patient data into the system 49
Week (4) Session (1)
System Implementation and Update
Policy

50
Week (4) Session (1)
Computer science Department
Executive Master in Cyber Security

Source of Slides and Refs:


Developing Cybersecurity
Programs and Policies, by
Omar Santos, 3rd Edition

Secure Code
Secure Code

▪ Two types of code


▪ Insecure code (referred as “sloppy code”)
▪ Sometimes the result of an amateurish effort, but more often than
not, it reflects a flawed process.
▪ Secure code
▪ Always the result of a deliberate process that prioritized security
from the beginning of the design phase onward.
▪ Deploying secure code is responsibility of the systems’ owner

52
Week (4) Session (1)
Secure Code
The Open Web Application Security Project
▪ The Open Web Application Security Project (OWASP)
▪ Open community dedicated to enabling organizations to develop,
purchase, and maintain applications that can be trusted
▪ Every 3 years releases the top 10 most critical web application
security flaws
▪ OWASP has created source code analysis tools (often referred to as
Static Application Security Testing (SAST) tools).
▪ tools are designed to analyze source code and/or compiled versions of code to
help find security flaws

53
Week (4) Session (1)
Secure Code
The Open Web Application Security Project Cont.
•Untrusted data is sent to an interpreter as part of a
command or query
Injection
•Preventing injection requires keeping untrusted data separate from
commands and queries

• The process of validating all the input to an application before using it


Input Validation • The objective of input validation is to evaluate the format of entered
information and, when appropriate, deny the input.

• Data that changes as updates become available—for example, an e-


Dynamic Data Verification commerce application that automatically calculates sales tax based on
the ZIP code entered

• The process of validating (and in some cases, masking) the output of a


Output Validation process before it is provided to the recipient

• Several runtime defenses and address randomization techniques exist


Runtime Defenses and Address
to prevent threat actors from performing code execution even if a
Randomization buffer (stack or heap-based) overflow takes place. (ASLR)&(PIE)
54
Week (4) Session (1)
Secure Code
Why Is Broken Authentication and Session Management Important?

▪ Examples
▪ the session can be hijacked or taken over by a malicious intruder.
▪ the identity of the authorized user can be impersonated.
▪ malicious intruders have the opportunity to continue an authenticated session

▪ A critical security design requirement must be strong


authentication and session management controls
▪ A common control for protecting authentication credentials
and session IDs is encryption.

55
Week (4) Session (1)
Application Development Policy

56
Week (4) Session (1)
Computer science Department
Executive Master in Cyber Security

In-Class
Activities

Discussion Question
Discussion Question
▪ Discussion Question 1
▪ Is it safe to install a minor software patch that is primarily a
bug fix?

58
Week (4) Session (1)
Summary
▪ Access control is a complex domain. Access to information is
extremely important to regulate.
▪ User access and user actions on the network must be monitored
and logged, whether they are located on premises or gaining
access to the network remotely.
▪ Monitoring is useless if the information gathered is not reviewed
regularly
▪ Data availability needs are at an all-time high. Custom
applications must be created with security in mind from the
start of the project, which includes a risk assessment and
proper input and output validation, along with regular security
tests.
▪ Patching a server is not a trivial task and should be accomplished
according to the path management policy.
59
Week (4) Session (1)
Building: 61
Room:

Contact:

Email address:
@kau.edu.sa

Chapter (#) 60

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy