INST569: Data and System Security

Lecture 5

Copyright © 2013 University of North America. All rights reserved. 1

 Key Terms and Concepts: Application &
Systems Development
• Life Cycle systems
Database Development Methodologies
– types
•• Security Engineering
Object-oriented Processes
databases
•• Change Management/control
Relational Databases
•• Build Management/control
Data Dictionaries
• Release Management/control
• Data Warehouses
• Capability Maturity Model (CMM)
• Artificial Intelligence
• Application Controls
•• Expert Systems
Application Control Types
•• Neural
SecurityNetworks
Control Architecture
• Application-related ThreatsControls
Implementation/Operation
• Attacks Methods
Distributed Computing Environment (DCE)
• Distributed Environment Security Mechanisms
• Development languages

Copyright © 2013 University of North America. All rights reserved.

 Application & Systems
Development Domain
• Development Life Cycle/Process
• Change Control/Configuration Management
• Application Controls
• Application environments/languages
• Applications – Databases, Data Warehouse, AI Systems,
• Threats and Attacks

Copyright © 2013 University of North America. All rights reserved.

 Applications and System
Development Security - Overview
• Addresses security as it relates to
– The development process
– The software/system being developed
– The type of software/system being deployed
• Provides the fundamentals required for an organization to be Proactive
rather than Reactive when addressing Application Security
• Reduces the risk of loss due to security vulnerabilities of applications
deployed by an organization - that can actually be controlled by the
organization
• Many of the concepts presented in this domain are similar to those
touted by TQM – Total Quality Management and have been adopted in
many organizations at some level. Very few, however, have used those
same concepts to explicitly address security to the level discussed in
this domain (Until recently, the business drivers that now make it a
priority did not exist for most industries).

Copyright © 2013 University of North America. All rights reserved.

 The world according to (ISC)2

• Application & Systems Development Security refers to

the controls included within systems and applications
and the steps used in their development.
• The term application applies to agents, applets,
software, databases, data warehouses, and knowledge-
based systems.

Copyright © 2013 University of North America. All rights reserved.

 Software Development Life Cycle
• Primary objective of any SW Development process is to
develop a quality product that meets customer
requirements within budget and schedule
• Early models were simplistic and assumed each process
step was complete before moving onto the next.
– System Requirements
– Analysis
– Program Design
– Coding
– Testing
– Operations & Maintenance

Copyright © 2013 University of North America. All rights reserved.

 SW Development Life Cycle
• Subsequent models recognized the need for iterating between steps
or for iterating through the process several times.
– Waterfall model, modified Waterfall, Spiral Model
– Verification - evaluate product in development against the specification.
– Validation - Evaluate against real-world requirements and concepts.
• Information Security should be handled like any other business
requirement and be addressed at every step of the development
process.

Copyright © 2013 University of North America. All rights reserved.

 Relevance to Security Architecture and
Models and Operations Security

• Separation of duties (Development, QA, Installation/Roll-out)

• Configuration/Change Management (applies to documentation
and hardware as well as software)
– Security Classification B2 and B3 requires configuration management be
enforced during development and maintenance
– Security Classification A1 requires configuration management be
enforced during the entire life cycle
• Certification – comprehensive evaluation of the technical and
non-technical security features of an information system
• Accreditation – formal declaration by a Designated Approving
Authority where an information system is approved for production

Copyright © 2013 University of North America. All rights reserved.

 Security Life Cycle Components –
System Feasibility

• Information Security Policy System Feasibility

• Standards
• Legal Issues SW Rqmts/Plans

Product Design

Detailed Design

Coding

Integration

‘Traditional or Waterfall Methodology’

Implementation

Operations/
Maintenance

Copyright © 2013 University of North America. All rights reserved.

 Security Life Cycle Components –
SW Plans & Requirements
Sy stem Feasibility

• Threats & Vulnerabilities

• Security Requirements SW Plans &
Requirements

• Reasonable Care, Due Diligence

• Legal Liabilities Product Design

• Desired Level of Protection Detailed Design

• Test Plans
Coding

Integration

‘Traditional or Waterfall Methodology’

Implementation

Operations/
Maintenance

Copyright © 2013 University of North America. All rights reserved.

 Security Life Cycle Components –
Product Design

• Incorporate Security Sy stem Feasibility

Specifications SW Plans &

Requirements

• Determine Access Control

• Evaluate Encryption Options Product Design

• Refine Test Plans

• Define Product Documentation Detailed Design

Coding

Integration

‘Traditional or Waterfall Methodology’

Implementation

Operations/
Maintenance

Copyright © 2013 University of North America. All rights reserved.

 Security Life Cycle Components – Detailed
Design

• Detailed Design Sy stem Feasibility

– Design Security Controls per

SW Plans &

legal requirements Requirements

– Design Access Controls

– Employ Encryption
Product Design

– Consider Business Continuity

Issues Detailed Design

• Detailed Test Plans/Scripts

• Detailed Documentation Coding

Design
Integration

Implementation

‘Traditional or Waterfall Methodology’

Operations/
Maintenance

Copyright © 2013 University of North America. All rights reserved.

 Security Life Cycle Components -
Coding

• Develop Security-related Code Sy stem Feasibility

• Support Business Continuity SW Plans &

Plan
Requirements

• Unit Testing Product Design

• Develop Documentation
Detailed Design

Coding

Integration

‘Traditional or Waterfall Methodology’

Implementation

Operations/
Maintenance

Copyright © 2013 University of North America. All rights reserved.

 Security Life Cycle Components -
Integration

• Integrate Security Components Sy stem Feasibility

• Integration Testing
• Conduct Security-related product SW Plans &
Requirements

verification Product Design

• Refine Documentation
Detailed Design

Coding

Integration

‘Traditional or Waterfall Methodology’

Implementation

Operations/
Maintenance

Copyright © 2013 University of North America. All rights reserved.

 Security Life Cycle Components –
Implementation

• Install Security Software Sy stem Feasibility

• Test Security Software

SW Plans &

• Complete Documentation,
Requirements

Certification, Accreditation Product Design

Detailed Design

Coding

Integration

‘Traditional or Waterfall Methodology’ Implementation

Operations/
Maintenance

Copyright © 2013 University of North America. All rights reserved.

 Security Life Cycle Components –
Operations & Maintenance

• Revalidate Security Controls

Sy stem Feaibility

• Conduct Penetration Testing and

Vulnerability Analysis SW Rqmts/Plans

• Implement Change Product Design

Management/Control Process
• Evaluate/Monitor SLA Detailed Design

Conformance
• Maintain Documentation
Coding

• Re-certification Integration

Implementation

‘Traditional or Waterfall Methodology’ Operations/

Maintenance

Copyright © 2013 University of North America. All rights reserved.

 Contemporary Development
Methodologies
• Rapid Application Development (RAD)

• Evolutionary Software Development

– Prototyping
– Spiral: This model of development combines the
features of the prototyping model and the waterfall
model.
– Incremental

• Concurrent Development Model

• Fourth Generation Development

Copyright © 2013 University of North America. All rights reserved.
 RAD
•Implications
Key Phases for Security Requirements?
– Business Modeling
– Data Modeling
Challenges and Barriers?
– Process Modeling
– Application generation
– Testing and Turnover

Source: Software Engineering: A

Practitioner’s Approach; Fourth Edition,
Roger S. Pressman; ISBN 0-07-052182-4

Copyright © 2013 University of North America. All rights reserved.

 Evolutionary Software Development

Implications for Security

Planning Requirements?
Risk Analysis

Challenges and Barriers?

Customer Communication

Entry Point
Engineering
Design

Customer
Evaluation
Construction
Release

Copyright © 2013 University of North America. All rights reserved.

 Relevance to Security Architecture and
Models and Operations Security

• Separation of duties (Development, QA, Installation/Roll-out)

• Configuration/Change Management (applies to documentation
and hardware as well as software)
– Security Classification B2 and B3 requires configuration management be
enforced during development and maintenance
– Security Classification A1 requires configuration management be
enforced during the entire life cycle
• Certification – comprehensive evaluation of the technical and
non-technical security features of an information system
• Accreditation – formal declaration by a Designated Approving
Authority where an information system is approved for production

Copyright © 2013 University of North America. All rights reserved.

 Capability Maturity Model
• Quality of a software product is directly related to the quality of the
development and maintenance process from which it is produced.

• Five Maturity Levels

– Initiating
– Repeatable
– Defined
– Managed
– Optimizing

Copyright © 2013 University of North America. All rights reserved.

 Application Controls
• Enforce an organizations security policy and procedures to maintain
Confidentiality, Integrity and Availability
– Data input
– Data processing
– Data output

Copyright © 2013 University of North America. All rights reserved.

 Application Controls Confidentiality
& Integrity
• Input Controls
– Data checks (range checking, validity checks)
– Date stamping during data create/edit
• Processing Controls
– Ensure accuracy of transaction processing – roll-backs, timely and
accurate re-processing invalid transactions
• Output Controls
– Input/Output comparison checks for data integrity
– Secured printer access, printer headings/banners, signed receipts for
printed material for confidentiality

Copyright © 2013 University of North America. All rights reserved.

 Application Controls Availability
• Service Level Agreement (SLA)
– Turn-around times
– Ave. response times
– # of on-line users
– System utilization rates
– System up-time
– Volume of transactions
– Production problems
• Two-phase commit – distributed databases

Copyright © 2013 University of North America. All rights reserved.

 Application Control Types

Application Accuracy Security Consistency

control type

Preventive Data checks, Firewalls, Data dictionary,

forms, custom sensitivity labels, programming
screens, validity encryption, standards
checks passwords, test
environments

Detective Hash controls, IDS and audit Comparison

cyclic redundancy trails controls,
checks relationship tests

Corrective Backups, Emergency Program

checkpoint response and comments and
restarts reference monitor database controls

Copyright © 2013 University of North America. All rights reserved.

 Security Control Architecture
(Covered in Domain 5)

 Defined Subset of Subjects and Objects

 Trusted Computing Base
 Security Perimeter
 Reference Monitor and Security Kernel
 Domains
 Resource Isolation
 Security Policy
 Least Privilege
 Layering, Data Hiding and Abstraction

Copyright © 2013 University of North America. All rights reserved.

 Implementation/Operation Controls

• All support personnel should be authorized

• Code Reviews (also part of Change Management) – prior to
implementation
• Separation of Duties
– Development staff should not review, implement systems
– Development staff should not support production data
– Development staff should not manage security function
• Accountability
– No access should be permitted directly to database
– Production data should be managed by users, not support staff
– All access to production data should be logged
• Least Privilege
– Access Control
– Access given to necessary data fields only
• Layered Defense – Access controls should be used in addition to
system access

Copyright © 2013 University of North America. All rights reserved.

 Distributed Environment

Geographically distributed components interconnected through one

or more network
• Client/Server
• Intranet/Internet - mobile code
– Applet – usually written in Java
• Distributed as an attachment in www document
• Navigator restricts applet file and network access to prevent security violations
• Full Java applications running outside of browser are not restricts
– Active X – MS answer to Java, COM-based technology that provides the
fundamental building blocks used in most Windows applications
• Agent/Proxy
– Used in client-server model, performs information preparation or exchange
for client or server

Copyright © 2013 University of North America. All rights reserved.

 Distributed Computing Environment (DCE)

An industry-standard software technology for setting up and managing

computing and data exchange in a system of distributed computers.

Copyright © 2013 University of North America. All rights reserved.

 Distributed Environment Security
Mechanisms
• Access Control
• Identification
• Authentication
• Intrusion Detection
• Emergency Response Plans
• Logs/Audit Trails
• Firewall/Browser configurations that restrict or prevent
downloading of applets

Copyright © 2013 University of North America. All rights reserved.

 SW Development Languages
• Interpreted languages
– Executes each instruction in real-time
– Also known as run-time binding
– Java
• Compiled languages
– Translates into machine code, which is executed by the
computer
– Binding occurs at compile time
– C++
– Higher security risk than interpreted because malicious code can
be embedded in the compiled code, making it difficult to detect

Copyright © 2013 University of North America. All rights reserved.

 JAVA

Programming language designed specifically for the Internet

Security Levels
– Untrusted – applets are not permitted to run
– High Security – applets are not permitted to read, write or delete files.
They cannot access WebView Settings. They may only connect to
and accept connections from their server of origin.
– Medium Security – applets can be granted permission to read, write
or delete files and access WebView Settings (after a warning is
displayed). Access to clipboard is not permitted.
– Low Security – applets run with minimal constraints. No warning are
generated for potentially unsafe actions. WebView generates a
warning if local applications are launched.

Copyright © 2013 University of North America. All rights reserved.

 Malicious Code

• Viruses – program code inserted into other program code with the intent of
causing an unexpected and undesirable event.
• File Infectors – attaches to program files, usually COM or EXE files and are
loaded when the program file is loaded.
• System/Boot Record Infectors – infects executable code found in certain
system areas or master boot records on the disk or to the DOS boot sector
on diskettes.
• Macro Viruses – infects applications, such as MS Word.
• Trojan Horses – a program or virus in which malicious or harmful code is
contained inside “apparently” harmless programs, data or messages.
• Logic Bombs – code inserted into an application or OS that executes when a
specified condition is met.
• Worm - a program that uses communications methods to propagate itself
between systems

Copyright © 2013 University of North America. All rights reserved.

 Object-Oriented Development
Methodology

• Provides the capability to model the “real-world”

• Has the potential of reducing propagation of program
errors
– Objects are encapsulated
– Messages are sent to request performance of defined
operations
– Provides a level of independence from other objects
• Over the long-term, increases code re-usability,
reducing development costs
– Requires disciplined process with upfront analysis and
design to reap the benefits

Copyright © 2013 University of North America. All rights reserved.

 Object Oriented Systems –
Fundamentals
• Subject – active entity, generally in the form of a person,
process, or device that causes information to flow among objects
or to change the system state
• Object – passive entity that contains or receives information
• Message – tells an object to perform an operation
• Method – defines actions performed in response to a message
• Behavior – results exhibited by an object upon receipt of a
message
• Class – a set of objects that share common structure and
behavior
• Instance – objects are instances of classes that contain their
methods

Copyright © 2013 University of North America. All rights reserved.

 Object Oriented Systems –
Fundamentals
• Inheritance (Multiple Inheritance) – Methods from one
class are inherited by a subclass
– Multiple inheritance – a class inherits behavioral characteristics
from more than one parent class
• Delegation – forwarding of a request by one object to
another
• Polymorphism – different objects may respond to a
common set of operations in different ways

Copyright © 2013 University of North America. All rights reserved.

 Object Oriented Systems –
Fundamentals
• Polyinstantiation – the development of a detailed version
of an object from another object using different values in
the new object.
• ORB (CORBA) – Object Request Broker –
locator/distributor of objects across a network. CORBA
is Common Object Request Broker, which defines an
industry standard allowing heterogeneous systems to
interface and communicate.
• COM (formerly OLE), DCOM – standard that supports
the exchange of common objects among programs.

Copyright © 2013 University of North America. All rights reserved.

 Database Systems - Types
• Hierarchical
• Mesh (Network)
• Object-oriented
• Relational

Copyright © 2013 University of North America. All rights reserved.

 Object-Oriented Databases
• “Subjects”
• “Objects”
• “Methods”
• Controls using encapsulation, inheritance, information hiding
• Permits classification of an object’s sensitivity through the use of
class and instance

Copyright © 2013 University of North America. All rights reserved.

 Relational Databases

• Relations - tables
• Tuples – rows or records
• Security can be provided via views – “virtual” relations
• Normalization – helps organize data and eliminate
redundancy
– First Normal Form – no repeating groups or multiple column values
– Second Normal Form – Non-key field must depend on primary key
– Third Normal Form – Non-key field cannot depend on primary key
• Referential Integrity – a system of rules used to ensure that
relationships between records in related tables are valid and
cannot be accidentally changed or deleted

Copyright © 2013 University of North America. All rights reserved.

 Relational DB Security Issues
• Aggregation
– The act of obtaining information of a higher sensitivity level by
combining information of lower sensitivity levels.
• Inference
– The ability of a user to infer or deduce information about data at
sensitivity levels for which they do not have access.
• Multi-level Security
– Enforces mandatory access controls in additional discretionary
access control to address confidentiality
– May create conflict between integrity and confidentiality when
integrity rules are enforced

Copyright © 2013 University of North America. All rights reserved.

 Relational DB Security Issues
(continued)
Polyinstantiation – also describes a situation where the same primary
key is used for different relations to store information at different
classification levels. Just by the act of attempting to create an
entry at the lower classification level with the same primary key
that exists at the higher classification level and having that
transaction fail, the user could INFER the classified data.

Copyright © 2013 University of North America. All rights reserved.

 Data Dictionary
• Database for developers
• Records the data structures used by an application
– Data elements
– Data element characteristics
– X-reference to programs/applications that use the data element
and associated files
• Serves as a control when programmers are required to
use the variable names from the Data Dictionary

Copyright © 2013 University of North America. All rights reserved.

 Data Warehousing/Data Mining
• Data Warehouse – repository of information from
heterogeneous databases made available to users for
reporting/queries
• Data Mining – analysis of data for relationships not
previously discovered. Results include
– Associations
– Sequences
– Classification
– Clustering
– Forecasting

Copyright © 2013 University of North America. All rights reserved.

 Additional Data Store - Memory
Covered in detail in Security Architecture and Security Model
Domain
• Primary (Real)
– Usually Random Access Memory
– Directly addressable by CPU
– Used for storage of instructions or data
• Secondary
– Slower, usually magnetic disc
– Non-volatile storage
• Virtual
– Uses secondary memory in conjunction with primary
– Provides a CPU with larger, apparent address space

Copyright © 2013 University of North America. All rights reserved.

 Additional Data Store – Memory
(continued)
• Random
– RAM – Random Access Memory
– Memory locations are directly addressed and data that is stored can
be altered
• Volatile
– Stored data is lost if power is removed from the system
– RAM is volatile
• Sequential
– Data is retrieved by sequentially searching the memory store from
the beginning rather than directly accessing the location
– Magnetic Tape

Copyright © 2013 University of North America. All rights reserved.

 Artificial Intelligence Systems
(Knowledge-based Systems)
Exhibits reasoning similar to that of a human being to solve
problems
• Expert System
• Neural Networks

Copyright © 2013 University of North America. All rights reserved.

 Expert System
• Knowledge base – in the form of rules about a particular
domain – based on human experiences
• Inference Engine – determines if the rules are satisfied
by the input

Copyright © 2013 University of North America. All rights reserved.

 Neural Networks
Based on the functioning of biological neurons
• Network of very simple processors, called neurons or
units – each with a small about of local memory
• Neurons are connected by unidirectional
communications channels
• Neuron operate on local data and inputs received via
connectors
• Training rule enables learning from examples and ability
to do generalizations

Copyright © 2013 University of North America. All rights reserved.

 Application-related Threats
• Trap Door
– Hidden Mechanism To Bypass
Protection Measures
• Letter bomb - email attachment with malicious code
• Back door - unapproved method of accessing the system
• Covert channel – Communication channel violating
information transfer policies
– Covert storage channel - Writing to storage through one
process, and reading by another (lower security level)
– Covert timing channel - Processes signal to one another by
modulating system use

Copyright © 2013 University of North America. All rights reserved.

 Methods of Attack
• Brute force – Trying all possible words and character
combinations to find the correct password, pass phrase
or PIN
• Denial of Service – An incident in which a user or
organization is deprived of the service of a resource they
would normally expect to have
• Dictionary Attacks – Attacker uses a pre-defined list of
dictionary words and tries each entry to see if it matches
a user’s password
• Spoofing – The user appears to be someone else or
manipulates packets so they appear to come from a
another system or network

Copyright © 2013 University of North America. All rights reserved.

 Methods of Attack (continued)
• Pseudo Flaw – An apparent loophole deliberately implanted in an
operating system program as a trap for intruders
• Alteration of authorized code
• Interrupts – An external signal interrupts normal program flow to
request service
• Remote Maintenance – Ability to access a system for maintenance
from a remote location, by-passing a system’s normal security
protections
• Browsing – The act of searching through storage to locate or
acquire information without necessarily knowing of the existence or
the format of the information being sought

Copyright © 2013 University of North America. All rights reserved.

 Methods of Attack (continued)
• Traffic analysis – Involves analyzing data characteristics (message
length, message frequency, etc…) and patterns of transmissions to
infer information
• Flooding – Forwarding by a router of a packet from any node to
every other node connected to the router
• Time of check/Time of use (TOC/TOU) – Exploits the difference in
the time that security controls were applied and the time the
authorized service was used

Copyright © 2013 University of North America. All rights reserved.

 Glossary
• Acceptance inspection – Final inspection to determine
whether or not a system meets the specified technical
and performance standards
• Assurance – A measure of confidence that the security
features and architecture of system accurately mediate
and enforce the security policy
• Configuration Control – The process of controlling
modifications to the system’s hardware, firmware,
software, and documentation that provides sufficient
assurance that the system is protected against the
introduction of improper modifications prior to, during,
and after system implementation.

Copyright © 2013 University of North America. All rights reserved.

 Glossary
• Configuration Management – The management of
security features and assurances through control of
changes made to system hardware, software, firmware,
documentation, test, test fixtures, and test
documentation throughout the development and
operational life of the system.
• Due Care – Minimum and customary practice of
responsible protection of assets that reflects a
community of social norm.
• Due Diligence – Prudent management and execution of
due care.

Copyright © 2013 University of North America. All rights reserved.

 Glossary

• Formal Development Methodology – A collection of

languages and tools that enforces a rigorous method of
verification.
• Formal Verification – The process of using formal proofs to
demonstrate the consistency between a formal specification
of a system and a formal security policy model (design
verification) or between the formal specification and its high-
level program implementation (implementation verification)
• Functional Testing – The segment of security testing in which
the advertised security mechanisms of the system are tested,
under operational conditions, for correct operation.

Copyright © 2013 University of North America. All rights reserved.

 Glossary
• Granularity – An expression of the relative size of a data
object; for example, protection at the file level is considered
coarse granularity, whereas protection at the field level is
considered to be of a finer granularity.
• Secure Configuration Management – The set of procedures
that are appropriate for controlling changes to a system’s
hardware and software structure for the purpose of ensuring
that changes will lead to violations of the system’s security
policy.
• Security Requirements – The types and level of protection that
are necessary for equipment, data, information, applications,
and facilities to meet security policy.

Copyright © 2013 University of North America. All rights reserved.

 Glossary
• Security Specifications – A detailed description of the
safeguards required to protect a system.
• Security Testing – A process that is used to determine that the
security features of a system are implemented as designed.
This process includes hands-on functional testing, penetration
testing, and verification.
• Top-level Specification – A nonprocedural description of system
behavior at the most abstract level; typically, a functional
specification that omits all implementation details.
• Work Factor – The effort or time needed to overcome
protective measures.

Copyright © 2013 University of North America. All rights reserved.