PAPER DSE 603(B) :CYBER SECURITY
UNIT-I: INTRODUCTION TO CYBER SECURITY, CYBER SECURITY VULNERABILITIES AND CYBER SECURITY SAFEGUARDS: INTRODUCTION TO CYBER SECURITY: OVERVIEW OF CYBERSECURITY, INTERNET GOVERNANCE – CHALLENGES AND CONSTRAINTS, CYBERTHREATS:- CYBER WARFARE-CYBER CRIME-CYBER TERRORISM-CYBER ESPIONAGE, NEED FORA COMPREHENSIVE CYBER SECURITY POLICY, NEED FOR A NODAL AUTHORITY, NEEDFOR AN INTERNATIONAL CONVENTION ON CYBERSPACE. CYBER SECURITYVULNERABILITIES: OVERVIEW, VULNERABILITIES IN SOFTWARE, SYSTEM ADMINISTRATION,COMPLEX NETWORK ARCHITECTURES, OPEN ACCESS TO ORGANIZATIONAL DATA, WEAKAUTHENTICATION, UNPROTECTED BROADBAND COMMUNICATIONS, POOR CYBER SECURITYAWARENESS. CYBER SECURITY SAFEGUARDS: OVERVIEW, ACCESS CONTROL, AUDIT,AUTHENTICATION, BIOMETRICS, CRYPTOGRAPHY, DECEPTION, DENIAL OF SERVICEFILTERS, ETHICAL HACKING, FIREWALLS, INTRUSION DETECTION SYSTEMS,RESPONSE, SCANNING, SECURITY POLICY, THREAT MANAGEMENT.
UNIT-II: SECURING WEB APPLICATION, SERVICES AND SERVERS: INTRODUCTION, BASICSECURITY FOR HTTP APPLICATIONS AND SERVICES, BASIC SECURITY FOR SOAPSERVICES, IDENTITY MANAGEMENT AND WEB SERVICES, AUTHORIZATION PATTERNS,SECURITY CONSIDERATIONS, CHALLENGES.
UNIT-III: INTRUSION DETECTION AND PREVENTION: INTRUSION, PHYSICAL THEFT, ABUSE OF PRIVILEGES, UNAUTHORIZEDACCESS BY OUTSIDER, MALWARE INFECTION, INTRUSION DETECTION AND PREVENTIONTECHNIQUES, ANTI-MALWARE SOFTWARE, NETWORK BASED INTRUSION DETECTIONSYSTEMS, NETWORK BASED INTRUSION PREVENTION SYSTEMS, HOST BASED INTRUSIONPREVENTION SYSTEMS, SECURITY INFORMATION MANAGEMENT, NETWORK SESSIONANALYSIS, SYSTEM INTEGRITY VALIDATION.
UNIT
II
SECURING
WEB APPLICATION, SERVICES AND SERVERS
Introduction
Initially, there were only very few real threats to the WWW: early on, hackers proved their ability and highlighted potential threats to the new environment by defacing web sites. Once commercial transactions (such as online shopping) and other high-value information exchanges were starting to use the web, the number of potential threat actors and threats grew quickly.
Web Services
Overview
Web services have become a widely used technology in both corporate and Internet applications. Web services have been defined in different ways; we use two principal realizations of distributed services that typically use HTTP for exchanging information:
Simple Object
Access Protocol(SOAP)
is a network protocol for exchanging structured data between nodes. SOAP services
are built around the concept of a SOAP envelope, an XML document that contains
a SOAP header, and a SOAP body. The header defines the necessary metadata for
the SOAP message, including processing instructions and security elements. The
SOAP body can-in principle-transport any media type, although the core protocol
was originally formulated around XML
documents.
HTTP services have been in use
since the early days of the WWW. The original design of the HTTP protocol included
not only the well-known operations such as GET (to retrieve data) or POST (to
modify data) which are commonly used by web browsers, but also PUT (to create
data) and DELETE (to delete data). In addition, HTTP also supports other
operations that allow comprehensive management of the service and the
interaction. Representational State Transfer (REST) is used to describe the architectural style of well designed
HTTP systems.
BASIC SECURITY FOR
HTTP APPLICATIONS AND SERVICES
Basic authentication and some other authentication and authorization mechanisms are built into the HTTP stack. At the same time, many of these security mechanisms were created to support web browsers, and often require considerable human interaction in order to work as designed.
Basic
Authentication
·
HTTP
provides “Basic Authentication” as part of the standard HTTP stack, where the
exchange of the credential is performed.
·
For
typical web applications, the server denies access to the resources that was
requested at the URI, and returns an
HTTP status code of 401, including a WWW-Authenticate header, which needs to be
set to the “Basic” authentication mechanism.
·
The
client then responds with another request to the same resource, but adds a
WWW-Authorization header with the Base64 encoding of the username and password.
The server can then decode the username and password and verify the credential.
Limitations:
1. This mechanism
transmits the username and password unencrypted. The simple Base64 encoding can
be decoded by anyone and must be treated as clear text.
2. Assigning
username/password accounts to machines tends to lead to bad code. Even if a
configuration file is used, the username and password are very often not
cryptographically protected on disk.
Transport Layer Security
Secure Socket Layer (SSL) is the most used internet security cryptographic protocol before the Transport Layer Security (TLS) was released in 1990. However, the SSL protocol has been discontinued, but the TLS has now adopted it. TLS is a popular security protocol designed for Internet communication to enhance privacy and data security. It is generally used to encrypt communication among web packages and servers, including a web browser loading page. It can be used for encrypting different voice messages for texts and IP. It was introduced by the Internet Technology Task Force (IETF) of the International Standards Organization (ISO), which launched the primary protocol in 1999. In 2018, the latest version was released and contained TLS 1.3.
In general, it is recommended to verify any TLS configuration with an appropriate scanning tool. While there any many commercial and free solutions available, a popular free web service for testing TLS setups can be found at https://www.ssllabs.com/.
Server
Authentication
·
Every
TLS transaction requires the server to authenticate itself to the client. This
is typically initiated by the client sending the server a list of supported TLS
versions, supported cipher-suites, and other connection information .
·
The
server responds with a list including the same information and also the server
PKI certificate.
·
The
client can then use the server certificate to authenticate the server, and
responds with a message that includes a master secret, which is used to
generate the session keys.
· Once the keys are available, the TLS handshake completes with the client and the server starting to use the session keys and shifting to an encrypted communication channel.
Mutual
Authentication
·
Mutual
authentication means that both client and server are authenticated to each
other.
·
This
is achieved by the server sending a Certificate Request message to the client
as part of the handshake.
· The client will then provide a user certificate to the server. This establishes the identity of the client to the server.
BASIC SECURITY FOR SOAP SERVICES
SOAP is a messaging protocol, meaning that
SOAP security is primarily concerned with preventing unauthorized access to
these messages and to users' information. The main thing used to accomplish
this is WS (Web Standards) Security.
WS Security is a set of principles that regulate the confidentiality and authentication procedures for SOAP messaging. WS Security-compliant measures include passwords, digital signatures and XML (Extensible Markup Language) encryption, among other things. XML encryption causes the data to be unreadable to unauthorized users.
What Is SOAP?
SOAP is an
abbreviation that stands for Simple Object Access Protocol. During the
implementation of web services in computer networking, structured information
is exchanged in various ways. SOAP is one such messaging protocol, and it is
used because it offers neutrality, independence, extensibility, and verbosity.
The message format is in XML (eXtensible Markup Language), and it uses
application layer protocols for negotiation and transmission, primarily HTTP,
with some legacy systems using SMTP.
Using SOAP, developers can invoke processes running on separate operating systems. They use XML to authenticate, authorize, and communicate. Web language protocols like HTTP and are usually installed and run regardless of the operating system; therefore, SOAP allows clients to invoke these web protocols to communicate independently of the operating platform or markup language.
How SOAP Works
SOAP messaging is a
stateless protocol, but a developer can build session control mechanisms into
the header to build a state into the transaction. This SOAP specification
allows asynchronous communication, which is artificially stateful, and it is
thus error-prone and can create vulnerabilities in the session-key management.
Web developers that know how to program in stateless environments can also build SOAP states using more traditional methods. For example, you can set the session attribute in the SOAP envelope header tag to mimic HTTP session cookies. You can also explicitly use cookies if using HTTP on the Transport Layer.
SOAP Message
Transmission
SOAP messages are
transmitted across multiple SOAP nodes – the SOAP sender, SOAP receiver, and
SOAP intermediaries who act as both senders and receivers. With this model,
dynamic routing across diverse transport layer protocols is possible.
Today, HTTP is the
primary transport layer in use. The distributed transaction model reduces the
functionality of transport layer security and increases the possibility of
attacks in the middle. HTTP is stateless and has some security vulnerabilities,
requiring that both client and server be online for communication to happen.
You can use other protocols to transport SOAP messages if you have different service level objectives that need to be accommodated. For example, if asynchronous transport mechanisms are required.
Why is SOAP
Security Important?
Cyber security is
on the list of top concerns of modern businesses. According to one source, the
average monetary loss due to malware attacks on companies is $2.4 million. Up
to 21% of files have no security measures or protections in place at all. This
not only makes the company’s data prone to attacks but also makes the
employee’s personal data and devices like their Mac prone to malware attacks.
SOAP security
protects oftentimes sensitive data that may otherwise fall into the wrong
hands. It is a means of integrating security into the APIs infrastructure and
protecting the interests of your clients.
Dream Factory brings additional safety to your data by building and monitoring APIs for you. We offer an API-as-a-service platform with rock-solid security measures.
Common SOAP
Security Risks
There are many
different kinds of cyber security vulnerabilities and attacks, and some are
uniquely aimed at APIs. A few of these are code injections, DoS (Denial of
Service), breached or leaked access/authorization, XSS (Cross-site Scripting)
and session hijacking. .
Code Injections
Code injections,
using SQL or, in the case of SOAP, XML, introduce malicious code into the
database or application itself. The only way to prevent these is with careful
access control.
Breached or Leaked
Access/Authorization
The majority of
attacks, including code injections, start with breached or leaked access.
Making sure SOAP messages get revealed only to the correct user is one
important part of SOAP security.
DoS
A Denial of
Service, or Distributed Denial of Service (DDoS) attack overwhelms and disrupts
a web service with messages that are too many or too long. SOAP security
includes measures that can make DoS attacks impossible by limiting the length
and volume of messages.
XSS(Cross-Site
Scripting)
Cross-site
scripting is another form of code injection, but more specifically it occurs
when someone injects malicious browser-side script into the web site through
the web application.
Session Hijacking
Session hijacking
is another failure of access control. It occurs when an unauthorized user
obtains a session ID. The user then has full access to the application and/or
another user’s account.
How to Build Secure
Web Services
Creating secure
SOAP Web Services is as simple as adding security layers to your SOAP headers.
You can add a security credential to the SOAP header, including username and
passwords, as variables. This way, when SOAP messages are generated, these
credentials are also generated, and the username and password will be required
when a user calls the web service.
The above is the most basic security measure, but there are best practices to ensure that your API is secured. These include:
Regular Testing
In this IoT era, few people perform regular testing on all devices connected to their server networks. You must implement testing procedures to ensure your SOAP API stands up to common threats and highlight vulnerabilities that hackers may exploit. Some types of tests include injection testing and fuzz testing. The former determines how your API reacts to unexpected input, while the latter detects vulnerable points where ransomware or malicious code can be introduced.
Identity and Access
Management (IAM)
This is the basic
layer of any cyber security protocol. It includes everything from usernames and
passwords to advanced authentication techniques like two-step verification. IAM
should prevent external users from accessing the application outside hours or stealing
session tokens and gaining entry into the sessions.
Request Monitoring
Involves monitoring
SOAP messaging and requests for abnormalities. You should, therefore, quickly
identify and resolve any data leaks or vulnerabilities. This uses logging systems,
which you can regularly check for any irregularities.
Input Validation
In SOAP, input
validation is divided into SOAP response validation and schema compliance
validation. The former ensures that the response to the SOAP message follows
the correct format, and the latter ensures that the message follows XML schema
and the Web Service Description Language (WSDL).
Redundant Security
Standards
There are many places of overlap in SOAP, XML, and WSDL standards. The purpose of redundant security standards is to provide insurance in these areas of overlap. With them in place, you have less chance of exposing sensitive data and a better chance of identifying vulnerabilities before hackers exploit them.
Web
Services and Identity Management
Web services and identity management systems has a circular relationship between them. As companies integrate more business applications using Web services, they find that establishing identity management is a critical prerequisite. And if they decide to implement a fully integrated, central identity management system, they find that Web services is the best way to integrate it with their various business applications and systems.
Why an IDMS?
The implementation
of an enterprise-wide identity management system is of great interest to
corporate security for several reasons.
• An IDMS will close
IT security gaps related to enrolling and terminating employees.
• The deployment of
an IDMS is typically accompanied by a role-based access control (RBAC) scheme
for the information systems. Once roles are jointly defined by human resources
and business managers, and once IT
security privileges are assigned to the roles, security privileges can be
automatically granted upon enrollment in the IDMS. Privileges are also
automatically changed when an employee's position changes, and revoked
automatically upon the employee's termination.
• Physical security
can leverage the defined corporate roles by defining access control privileges
to match, aligning physical security more tightly with the organization's job
roles. This doesn't require the access control system to be integrated to any
other system.
• Physical security
can leverage the HR enrollment of employees by integrating the physical access
control system (PACS) with the IDMS, so that access control privileges are
managed automatically along with IT privileges as HR enrolls, re-assigns and
terminates employees.
Using an IDMS as a
common point of reference, physical and IT access control can be synchronized.
And using role-based access control to establish privileges based upon job
functions, both physical and IT access control can be policy-driven.
Even if no identity management system is used and the physical and IT access control systems are not integrated with each other, RBAC can be used in both physical and IT systems to provide a policy-driven access control approach that aligns with the organization. Maintaining this scheme requires more human attention than with integrated systems. On the other hand, it does strengthen security while making it very manageable and auditable.
AUTHORIZATION
PATTERNS
In addition to the authentication mechanism (such as a password), access control is concerned with how authorization patterns are structured.
Access Control
Models
Early systems
implemented fairly simple access control models that rely mostly on the
identity of the user and define access control lists (ACLs) that are stored
with the resource that is subject to that access control list.
This model has
sometimes been called “Identity Based Access Control” (IBAC) and has proven to
be very efficient and easy to implement.
Other access control models include (Role-Based Access Control) RBAC and ABAC(Attribute- Based Access Control) are better in separation of resources and applicable access control policies comparing to IBAC.
eXtensible Access
Control Markup Language Overview
XACML is used to promote
interoperability and common terminology for access control implementations,
where access attributes associated with a user are used to decide whether a
user may have access to a specific resource.
Within the XACML
model, there are a number of actors that enable the distributed authorization
environment. Note that some of these actors can be co-located: certain
appliances or access managers allow configurations where PEP, PDP, and PAP are
co-located, as discussed in the following components:
·
Access
requester (or client). This is the entity that initiates a request.
·
Policy
Enforcement Point (PEP). The PEP intercepts the request from the client to the
resources and performs an authorization check. This actor is sometimes
integrated with a reverse proxy (a façade service that wraps the resource and
replicates the resource’s interface to the clients).
·
Policy
Decision Point (PDP). The PDP performs the actual policy evaluation, based on
the information in the request from the PEP, a policy set (the merged set of
applicable policies, based on a policy merging systems), configured attribute
sources, and other environmental factors (such as time of day, origin or destination
of request, etc.).
· Policy
Administration Point (PAP). The policy administration point allows the
configuration and administration of applicable access control policies. The PDP
is configured through the PAP to use a specific set of policies.
·
Policy
Information Point (PIP). The PIP provides contextual information input into the
policies, based on a request from the PDP. If the PIP provides specific attributes
for identities, e.g., in the form of a Directory Server, the PIP is sometime
also called an Attribute Source (AS).
· Resource. The resource itself provides the service for the client. While XACML is typically used for SOAP services, there is no requirement for the resource to be implemented as a SOAP service. For example, a combined PEP/service façade can be used to expose the functionality of a legacy application to SOAP-enabled clients.
SECURITY
CONSIDERATIONS
Security
considerations are essential to implementing and integrating a comprehensive
strategy for managing risk for all IT assets in an organization. This should
result in more cost-effective, risk-appropriate security control
identification, development, and testing.
Avoiding
Common Errors
The flexibility of web-based systems
and the ease of implementing new services lead to an early proliferation of web
applications and web services. It became obvious pretty quickly that these new
technologies resulted in a number of mistakes that were independently made by
many developers. Security research groups and organizations started to look
into this problem and identified a number of anti patterns and mistakes that
were particularly common, and identified measure to counter them. The following
gives an overview of two commonly referred to lists of common mistakes and
useful controls, respectively.
Open
Web Application Security Project (OWASP) Top 10
The
Open Web Application Security Project (OWASP) Top 10 list15 was developed by
the OWASP community to enumerate common problems with web applications.
A1:
Injection flaws,
such as SQL, OS, and LDAP injection may occur when untrusted data is sent to a
web service trying to exploit the underlying business logic.
A2:
Broken Authentication and Session Management. If access to the HTTP resources where the service is
host is not protected properly, arbitrary users may invoke the service and
cause confidentiality and integrity problems.
Authentication issues can arise when the verification of accounts with
the user database is compromised, user information is leaked through other
channels, or the authentication session parameters are not set properly.
A4:
Insecure Direct Object References.
If input of the access URL (for REST-style services) or the content of the SOAP
request is not verified through input validation techniques, a malicious user
may replace legitimate data references with improper data. For example, if a
service call should reference Alice’s account for receiving a money transfer, a
malicious attacker could try to replace Alice’s account number with Eve’s, thus
redirecting the transfer to a wrong account.
A5:
Security Misconfiguration.
This can include default account, unpatched or unmaintained server code,
references to old versions of services, etc. Any security misconfiguration can
be exploited by attackers to gain access, elevate privileges, or violate
confidentiality or integrity of the data.
A6:
Sensitive Data Exposure.
Web services can easily expose sensitive data including authentication
information, PII, financial, or health data.
A8:
Using Components with Known Vulnerabilities. Web services rely on a large stack of third-party
software, including the operating system, format parsers, virtual machines, web
servers, application servers, cryptographic libraries, and many other tools.
Any known vulnerability in this third-party code may lead to a compromise of
the entire service.
Center
for Internet Security Top 20 Critical Security Controls
The
Center for Internet Security (CIS) Top 20 list of critical security controls 16
enumerates the most important technical and administrative controls to prevent
or limit attacks on computer systems. The list was developed by a number of
experts from the US. The controls themselves are generic and not specific to
web services. At the same time, they can be applied to the architectural
concepts, technologies, and deployed systems implementing web services.
Critical
Control 3: Secure Configurations for Hardware and Software on Laptops,
Workstations, and Servers
This
control requires a secure configuration of all system components. This can be
implemented by creating standard system images that are hardened against
attacks. Such hardening may include disabling nonessential system services,
limiting the visibility to network probes, configuring kernel-level security
enforcement rules, etc. A secure baseline operating system limits the potential
damage that a misconfigured or compromised web service or client can cause.
Critical
Control 4: Continuous Vulnerability Assessment and Remediation
The
window for attacking weak systems is significantly reduced by continuously
monitoring and assessing the vulnerability profile of all deployed systems.
With a comprehensive program in placed that should ideally consist of automated
and human components potential weaknesses in the web service application
runtime or the implementing code itself can be detected and fixed in near real
time. This minimizes the attack window for threat actors significantly.
Critical
Control 9: Limitation and Control of Network Ports, Protocols, and Services
It
is crucial to have a comprehensive list of allowed port, protocols, and system
services for all active and passive network devices. Each individual component
must only be allowed to perform its designated function and use the appropriate
set of network resources to do so. This way compromised devices can be
identified much more easily:
if
a server designated to provide web service over HTTPS suddenly starts to send
out Border Gateway Protocol (BGP) messages, network monitors and intrusion
detection and prevention systems can react immediately and take that system off
the network to prevent unauthorized routing of data.
Critical
Control 11: Secure Configurations for Network Devices Such as Firewalls
,Routers, and Switches
Not
only the actual business systems such as servers and client, but also the
supporting network infrastructure components need to be configured in the most
secure way. This control is complementary to Critical Control 3, and should be
implemented equivalently.
Critical
Control 12: Boundary Defense
Firewalls
and other boundary defense technologies have been available for a long time,
and despite them having a bad reputation for preventing advanced attacks, they
are very useful in preventing certain classes of vulnerabilities.
A
solid boundary defense also enables close monitoring of data ingress and
egress, and allows to inspect and control information flow from the web service
to the client and vice versa. Separating the rest of the world from the
internal networks also make monitoring of the use of ports, protocols, and
service (Critical Control 9) much easier.
Critical
Control 17: Security Skills Assessment and Appropriate Training to Fill Gaps
All
personnel involved in the creation and maintenance of the web service must be
qualified to perform their job functions. While this seems like an ancient IT
adage, many IT architects, developers, and administrators have a hard time
staying on top of their field both from an application and security
perspective. Security training and evaluations should be part of everyone’s responsibility.
Exploring
the usefulness of relevant security certifications for key staff members may
augment this. Overall, only senior-level management sponsorship can ensure the
successful implementation of this control.
Critical
Control 18: Application Software Security
In
the context of the SANS Top 20, this control focuses on the security of the
code implementing the service itself. While there are other frameworks
available as well, the OWASP Top 10 list (see Fig. 10.7) is a good starting
point for assessing the security of the service and client software quality.
Critical
Control 20: Penetration Tests and Red Team Exercises
Even
the best security engineering teams will make mistakes or miss possible attack
vectors when protecting critical resources such as web services. Only a
comprehensive penetration test and recurring exercises can expose potential
security flaws. More details on creating a test program for web services are
explained later in the chapter.
Testing
and Vulnerability Assessment Testing Strategy
As
identified in the CIS Top 20 list of Critical Controls and many other
documentations of security best practices, testing and continuous monitoring
are central to maintaining a secure environment. While tests during the design
of a software package such as a service are standard development practices, the
deployed service itself should be evaluated in context as well.
Such
tests can include simple functional tests that verify the invocation of a
service call in the deployed environment (or a mockup of that environment), but
they may also include performance tests to ensure that the service behaves
correctly under heavy load. There are a number of commercial and open source
tools available for performing such test, including the popular soap UI framework22
or webInject23 open source projects.
Vulnerability
Assessment Tools
In
addition to functional testing at development and deploy time web services
should undergo at least a vulnerability assessment to determine their actual
vulnerabilities (see Sidebar: “Vulnerability Assessment Versus Penetration
Testing”). Such a vulnerability assessment is focused on determining the
problems with the exposed service, from a number of different angles.
To
perform a comprehensive vulnerability assessment of a service installation, the
analyst should be familiar with the base techniques of vulnerability
assessments for servers. There are many
tools available for performing such an assessment, both commercial as well as
open source-based solutions. Specialized Linux distributions such as Kali
Linux24 are specifically designed for vulnerability assessments and testing,
and have many of the best tools preinstalled. For HTTP-based systems, testers
should minimally employ w3af, MetaSploit, openVAS, and Nessus in addition
to other standard tools.
Finally,
let’s take a brief look at the web applications, services, and servers
challenges that still need to be addressed. The following checklist (see
checklist: “An Agenda for Action for Security Actions That Web Applications,
Services, and Servers Need to Consider”) discusses several web applications,
services, and servers security challenges in detail, including web services
discovery, quality of service, quality of protection, and protection from
denial of service attacks.
CHALLENGES
While
many of the web applications, services, and server challenges have been met
with existing standards, there are a number of challenges that standards
organizations are addressing particularly in the area of web services discovery
and reliability. The Web Services Interoperability Organization (WS-I)
acknowledges that there are many challenges that have yet to be addressed. Some
examples of these challenges are:
·
Repudiation
of transactions;
·
Secure
issuance of credentials;
·
Exploitation
of covert channels;
·
Compromised
services;
·
Spread
of malware, such as viruses and Trojan horses via SOAP messages;
·
Denial
of service attacks;
·
Incorrect
service implementations.
No comments:
Post a Comment