Certification

(My) CISSP Notes – Security Architecture and Design

Adrian Citu1 Comment

Note: This notes were made using the following books: “CISPP Study Guide” and “CISSP for dummies”.

Security Architecture and Design describes fundamental logical hardware, operating system, and software security components, and how to use those components to design, architect, and evaluate secure computer systems.

Security Architecture and Design is a three-part domain. The first part covers the hardware and software required to have a secure computer system. The second part covers the logical models required to keep the system secure, and the third part covers evaluation models that quantify how secure the system really is.

Secure system design concepts

Layering separates hardware and software functionality into modular tiers. A generic list of security architecture layers is as follows:

1. Hardware

2. Kernel and device drivers

3. Operating System

4. Applications

Abstraction hides unnecessary details from the user. Complexity is the enemy of security: the more complex a process is, the less secure it is.

A security domainis the list of objects a subject is allowed to access. Confidential, Secret, and Top Secret are three security domains used by the U.S. Department of Defense (DoD), for example. With respect to kernels, two domains are user mode and kernel mode.

The ring model is a form of CPU hardware layering that separates and protects domains (such as kernel mode and user mode) from each other. Many CPUs, such as the Intel ×86 family, have four rings, ranging from ring 0 (kernel) to ring 3 (user).

The rings are (theoretically) used as follows:

• Ring 0: Kernel

• Ring 1: Other OS components that do not fit into Ring 0

• Ring 2: Device drivers

• Ring 3: User applications

Processes communicate between the rings via system calls, which allow processes to communicate with the kernel and provide a window between the rings.The ring model also provides abstraction: the nitty-gritty details of saving the file are hidden from the user, who simply presses the “save file” button.  A new mode called hypervisor mode (and informally called “ring 1”) allows virtual guests to operate in ring 0, controlled by the hypervisor one ring “below”.

An open system uses open hardware and standards, using standard components from a variety of vendors. An IBM-compatible PC is an open system.

A closed system uses proprietary hardware or software.

Secure hardware architecture

Secure Hardware Architecture focuses on the physical computer hardware required to have a secure system.

The system unit is the computer’s case: it contains all of the internal electronic computer components, including motherboard, internal disk drives, power supply, etc. The motherboard contains hardware including the CPU, memory slots, firmware, and peripheral slots such as PCI (Peripheral Component Interconnect) slots.

A computer bus, is the primary communication channel on a computer system. Communication between the CPU, memory, and input/output devices such as keyboard, mouse, display, etc., occur via the bus. Some computer designs use two buses: a northbridge and southbridge. The northbridge, also called the Memory Controller Hub (MCH), connects the CPU to RAM and video memory. The southbridge, also called the I/O Controller Hub (ICH), connects input/output (I/O) devices, such as disk, keyboard, mouse, CD drive, USB ports, etc. The northbridge is directly connected to the CPU, and is faster than the southbridge.

The “fetch and execute” (also called “Fetch, Decode, Execute,” or FDX) process actually takes four steps: 1. Fetch Instruction 1 2. Decode Instruction 1 3. Execute Instruction 1 4. Write (save) result 1 These four steps take one clock cycle to complete.

Pipelining combines multiple steps into one combined process, allowing simultaneous fetch, decode, execute, and write steps for different instructions.

An interrupt indicates that an asynchronous event has occurred. CPU interrupts are a form of hardware interrupt that cause the CPU to stop processing its current task, save the state, and begin processing a new request. When the new task is complete, the CPU will complete the prior task.

A processis an executable program and its associated data loaded and running in memory. A parent process may spawn additional child processes called threads. A thread is a light weight process (LWP). Threads are able to share memory, resulting in lower overhead compared to heavy weight processes.

Applications run as processes in memory, comprised of executable code and data. Multitasking allows multiple tasks (heavy weight processes) to run simultaneously on one CPU.

Multiprogramming is multiple programs running simultaneously on one CPU; multitasking is multiple tasks (processes) running simultaneously on one CPU, and multithreading is multiple threads (light weight processes) running simultaneously on one CPU.

Multiprocessing has a fundamental difference from multitasking: it runs multiple processes on multiple CPUs.

A watchdog timer is designed to recover a system by rebooting after critical processes hang or crash. The watchdog timer reboots the system when it reaches zero.

CISC (Complex Instruction Set Computer) and RISC(Reduced Instruction Set Computer) are two forms of CPU design. CISC uses a large set of complex machine language instructions, while RISC uses a reduced set of simpler instructions.

Real (or primary) memory, such as RAM, is directly accessible by the CPU and is used to hold instructions and data for currently executing processes. Secondary memory, such as disk-based memory, is not directly accessible.

Cache memoryis the fastest memory on the system, required to keep up with the CPU as it fetches and executes instructions. The fastest portion of the CPU cache is the register file. The next fastest form of cache memory is Level 1 cache, located on the CPU itself. Finally, Level 2 cache is connected to (but outside) the CPU.

RAM is volatile memory used to hold instructions and data of currently running programs.

Static Random Access Memory (SRAM) is expensive and fast memory.

Dynamic Random Access Memory (DRAM) stores bits in small capacitors (like small batteries), and is slower and cheaper than SRAM.

ROM (Read Only Memory) is nonvolatile: data stored in ROM maintains integrity after loss of power.

Addressing modes are CPU-dependent; commonly supported modes include direct, indirect, register direct, and register indirect. Direct mode says “Add X to the value stored in memory location #YYYY.” That location stores the number 7, so the CPU adds X + 7. Indirectstarts the same way: “Add X to the value stored in memory location #YYYY.”  The difference is #YYYY stores another memory location (#ZZZZ). The CPU follows to pointer to #ZZZZ, which holds the value 7, and adds X + 7. Register direct addressing is the same as direct addressing, except it references a CPU cache register. Register indirect is also the same as indirect, except the pointer is stored in a register.

Memory protectionprevents one process from affecting the confidentiality, integrity, or availability of another.

Process isolation is a logical control that attempts to prevent one process from interfering with another. This is a common feature among multiuser operating systems such as Linux, UNIX, or recent Microsoft Windows operating systems.

Hardware segmentation takes process isolation one step further by mapping processes to specific memory locations.

Virtual memory provides virtual address mapping between applications and hardware memory.

Swapping uses virtual memory to copy contents in primary memory (RAM) to or from secondary memory (not directly addressable by the CPU, on disk). Swap space is often a dedicated disk partition that is used to extend the amount of available memory. If the kernel attempts to access a page (a fixed-length block of memory) stored in swap space, a page fault occurs (an error that means the page is not located in RAM), and the page is “swapped” from disk to RAM. The terms “swapping” and “paging” are often used interchangeably, but there is a slight difference: paging copies a block of memory to or from disk, while swapping copies an entire process to or from disk.

Firmware stores small programs that do not change frequently, such as a computer’s BIOS (discussed below), or a router’s operating system and saved configuration. Various types of ROM chips may store firmware, including PROM, EPROM, and EEPROM.

Flash memory (such as USB thumb drives) is a specific type of EEPROM, used for small portable disk drives. The difference is any byte of an EEPROM may be written, while flash drives are written by (larger) sectors. This makes flash memory faster than EEPROMs, but still slower than magnetic disks.

The IBM PC-compatible BIOS(Basic Input Output System) contains code in firmware that is executed when a PC is powered on. It first runs the Power-On Self-Test (POST), which performs basic tests, including verifying the integrity of the BIOS itself, testing the memory, identifying system devices, among other tasks. Once the POST process is complete and successful, it locates the boot sector (for systems which boot off disks), which contains the machine code for the operating system kernel. The kernel then loads and executes, and the operating system boots up.

WORM(Write Once Read Many) Storage can be written to once, and read many times. WORM storage helps assure the integrity of the data it contains: there is some assurance that it has not been (and cannot be) altered, short of destroying the media itself. The most common type of WORM media is CD-R (Compact Disc Recordable) and DVD-R (Digital Versatile Disk Recordable). Note that CD-RW and DVD-RW (Read/Write) are not WORM media.

Techniques used to provide process isolation include virtual memory (discussed in the next section), object encapsulation, and time multiplexing.

Secure operating system and software architecture

Secure Operating System and Software Architecture builds upon the secure hardware described in the previous section, providing a secure interface between hardware and the applications (and users) which access the hardware.

Kernels have two basic designs: monolithic and microkernel. A monolithic kernelis compiled into one static executable and the entire kernel runs in supervisor mode. All functionality required by a monolithic kernel must be precompiled in. Microkernelsare modular kernels. A microkernel is usually smaller and has less native functionality than a typical monolithic kernel (hence the term “micro”), but can add functionality via loadable kernel modules. Microkernels may also run kernel modules in user mode (usually ring 3), instead of supervisor mode.  A core function of the kernel is running the reference monitor, which mediates all access between subjects and objects. It enforces the system’s security policy, such as preventing a normal user from writing to a restricted file, such as the system password file.

Microsoft NTFS (New Technology File System) has the following basic file permissions:

• Read

• Write

• Read and execute

• Modify

• Full control (read, write, execute, modify, and delete)

Setuid is a Linux and UNIX file permission that makes an executable run with the permissions of the file’s owner, and not as the running user. Setgid (set group ID) programs run with the permissions of the file’s group. Setuid programs must be carefully scrutinized for security holes: attackers may attempt to trick the passwd command to alter other files.

Virtualization adds a software layer between an operating system and the underlying computer hardware. This allows multiple “guest” operating systems to run simultaneously on one physical “host” computer. There are two basic virtualization types: transparent virtualization (sometimes called full virtualization) and paravirtualization. Transparent virtualization runs stock operating systems, such as Windows 7 or Ubuntu Linux 9.10, as virtual guests. No changes to the guest OS are required. Paravirtualization runs specially modified operating systems, with modified kernel system calls.

Thin clientsare simpler than normal computer systems, with hard drives, full operating systems, locally installed applications, etc. They rely on central servers, which serve applications and store the associated data.Thin client applications normally run on a system with a full operating system, but use a Web browser as a universal client, providing access to robust applications which are downloaded from the thin client server and run in the client’s browser.

A diskless workstation (also called diskless node) contains CPU, memory, and firmware, but no hard drive. Diskless devices include PCs, routers, embedded devices, and others.

System vulnerabilities, threads and countermeasures

System Threats, Vulnerabilities, and Countermeasures describe security architecture and design vulnerabilities, and the corresponding exploits that may compromise system security.

Emanations are energy that escape an electronic system, and which may be remotely monitored under certain circumstances.

A covert channelis any communication that violates security policy. Two specific types of covert channels are storage channels and timing channels. The opposite of as covert channel is an overt channel: authorized communication that complies with security policy. A storage channel example uses shared storage, such as a temporary directory, to allow two subjects to signal each other. A covert timing channel relies on the system clock to infer sensitive information.

Buffer overflows can occur when a programmer fails to perform bounds checking.

Time of Check/Time of Use (TOCTOU) attacks are also called race conditions: an attacker attempts to alter a condition after it has been checked by the operating system, but before it is used. The term race condition comes from the idea of two events or signals that are racing to influence an activity.

A backdoor is a shortcut in a system that allows a user to bypass security checks (such as username/password authentication) to log in.

Malicious Code or Malware is the generic term for any type of software that attacks an application or system.

  • Zero-day exploits are malicious code (a threat) for which there is no vendor-supplied patch (meaning there is an unpatched vulnerability). Zero-day exploits are malicious code (a threat) for which there is no vendor-supplied patch (meaning there is an unpatched vulnerability).
  •  A rootkitis malware which replaces portions of the kernel and/or operating system. A user-mode rootkit operates in ring 3 on most systems, replacing operating system components in “userland.” Commonly rootkitted binaries include the ls or ps commands on Linux/UNIX systems, or dir or tasklist on Microsoft Windows systems. A kernel-mode rootkit replaces the kernel, or loads malicious loadable kernel modules. Kernel-mode rootkits operate in ring 0 on most operating systems.
  • A logic bomb is a malicious program that is triggered when a logical condition is met.
  • Packers provide runtime compression of executables. The original exe is compressed, and a small executable decompresser is prepended to the exe. Upon execution, the decompresser unpacks the compressed executable machine code and runs it.

Server-side attacks

Server-side attacks (also called service-side attacks) are launched directly from an attacker (the client) to a listening service. Server-side attacks exploit vulnerabilities in installed services.

Client-side attacks

Client-side attacks occur when a user downloads malicious content. The flow of data is reversed compared to server-side attacks: client-side attacks initiate from the victim who downloads content from the attacker.

Security Assertion Markup Language (SAML) is an XML-based framework for exchanging security information, including authentication data.

Polyinstantiation allows two different objects to have the same name. The name is based on the Latin roots for multiple (poly) and instances (instantiation).

Database polyinstantiation means two rows may have the same primary key, but different data (!!!????).

Inference and aggregation occur when a user is able to use lower level access to learn restricted information.

Inference requires deduction: clues are available, and a user makes a logical deduction.

Aggregation is similar to inference, but there is a key difference: no deduction is required.

Security Countermeasures

The primary countermeasure to mitigate the attacks described in the previous section is defense in depth: multiple overlapping controls spanning across multiple domains, which enhance and support each other.

System hardening , systems configured according to the following concepts:

  • remove all unnecessary components.
  • remove all unnecessary accounts.
  • close all unnecessary network listening ports.
  • change all default passwords to complex, difficult to guess passwords
  • all necessary programs should be run at the lowest possible privilege.
  • security patches should be install as soon as they are available.

Heterogenous environment  The advantage of heterogenous environment is its variety of systems; for one thing, the various types of systems probably won’t possess common vulnerabilities, which makes them harder to attack.

System resilience The resilience of a system is a measure of its ability to keep running, even under less-than-ideal conditions.

Security models

Security models help us to understand sometimes-complex security mechanisms in information systems. Security models illustrate simple concepts that we can use when analyzing an existing system or designing a new one.

The concepts of reading down and writing upapply to Mandatory Access Control models such as Bell-LaPadula. Reading down occurs when a subject reads an object at a lower sensitivity level, such as a top secret subject reading a secret object. There are instances when a subject has information and passes that information up to an object, which has higher sensitivity than the subject has permission to access. This is called “writing up” because the subject does not see any other information contained within the object. The only difference between reading up and writing down is the direction that information is being passed.

Access Control Models

  • A state machine model is a mathematical model that groups all possible system occurrences, called states. Every possible state of a system is evaluated, showing all possible interactions between subjects and objects. If every state is proven to be secure, the system is proven to be secure.
  • The Bell-LaPadula model was originally developed for the U.S. Department of Defense. It is focused on maintaining the confidentiality of objects.Bell-LaPadula operates by observing two rules: the Simple Security Property and the * Security Property. The Simple security property states that there is “no read up:” a subject at a specific classification level cannot read an object at a higher classification level. The * Security Property is “no write down:”a subject at a higher classification level cannot write to a lower classification level. Bell-LaPadula also defines 2 additional properties that will dictate how the system will issue security labels for objects.  The Strong Tranquility Propertystates that security labels will not change while the system is operating.The Weak Tranquility Property states that security labels will not change in a way that conflicts with defined security properties.
  • Take-Grant systems specify the rights that a subject can transfer to a from another subject or object. These rights are defined through four basic operations: create, revoke, take and grant.
  • Biba integrity model (sometimes referred as Bell-LaPadula upside down) was the first formal integrity model.  Biba is the model of choice when integrity protection is vital. The Biba model has two primary rules: the Simple Integrity Axiom and the * Integrity Axiom. The Simple Integrity Axiom is “no read down:”a subject at a specific classification level cannot read data at a lower classification. This protects integrity by preventing bad information from moving up from lower integrity levels.The * Integrity Axiom is “no write up:”a subject at a specific classification level cannot write to data at a higher classification. This protects integrity by preventing bad information from moving up to higher integrity levels.

Biba takes the Bell-LaPadula rules and reverses them, showing how confidentiality and integrity are often at odds. If you understand Bell LaPadula (no read up; no write down), you can extrapolate Biba by reversing the rules: no read down; no write up.

  • Clark-Wilson is a real-world integrity model (this is an informal model) that protects integrity by requiring subjects to access objects via programs. Because the programs have specific limitations to what they can and cannot do to objects, Clark-Wilson effectively limits the capabilities of the subject.Clark-Wilson uses two primary concepts to ensure that security policy is enforced; well-formed transactions and Separation of Duties.
  • The Chinese Wall model is designed to avoid conflicts of interest by prohibiting one person, such as a consultant, from accessing multiple conflict of interest categories (CoIs). The Chinese Wall model requires that CoIs be identified so that once a consultant gains access to one CoI, they cannot read or write to an opposing CoI.
  • The noninterference model ensures that data at different security domains remain separate from one another.

Evaluation methods, certification and accreditation

Evaluation criteria provide a standard for qualifying the security of a computer system or network. These criteria include the Trusted Computer System Evaluation Criteria (TCSEC), Trusted Network Interpretation (TNI), European Information Technology Security Evaluation Criteria (ITSEC) and the Common Criteria.

 Trusted Computer System Evaluation Criteria (TCSEC)

TCSEC commonly known as the Orange Book and it’s the formal implementation of the Bell-LPadula model. The evaluation criteria were developed to achieve the following objectives:

  • Measurement Provides a metric for assessing comparative levels of trust between different computer systems.
  • Guidance Identifies standard security requirements that vendors must build into systems to achieve a given trust level.
  • Acquisition Provides customers a standard for specifying acquisition requirements and identifying systems that meet those requirements.

The Orange Book was the first significant attempt to define differing levels of security and access control implementation within an IT system.

The Orange Book defines four major hierarchical classes of security protection and numbered subclasses (higher numbers indicate higher security) :

  • D: Minimal protection
  • C: Discretionary protection (C1 and C2)
  • B: Mandatory protection (B1, B2 and B3)
  • A: Verified protection (A1)

Trusted Network Interpretation (TNI)

TNI adresses confidentiality and integrity in trusted computer/communications network systems. Within the Rainbow Series, it’s known as the Red Book.

European Information Technology Security Evaluation Criteria (ITSEC)

ITSEC addresses confidentiality, integrity and availability, as well as evaluating an entire system defined as Target of Evaluation (TOE), rather than a single computing platform.

ITSEC evaluates functionality (F, how well the system works) and assurance (E the ability to evaluate the security of  a system).   Assurance correctness ratings range from E0 to E6.

The equivalent ITSEC/TCSEC ratings are:

  • E0:D
  • F-C1,E1:C1
  • F-C2,E2:C2
  • F-B1,E3:B1
  • F-B2,E4:B2
  • F-B3,E5:B3
  • F-B3,E6:A1

Common criteria

The International Common Criteria is an internationally agreed upon standard for describing and testing the security of IT products. It is designed to avoid requirements beyond current state of the art and presents a hierarchy of requirements for a range of classifications and systems.

The common criteria defines eight evaluation assurance levels (EALs): EAL0 through EAL7 in order of increasing level of trust.

System Certification and Accreditation

System certification is a formal methodology for comprehensive testing and documentation of information system security safeguards, both technical and non-technical, in a given environment by using established evaluation criteria (the TCSEC).

Accreditation is an official, written approval for the operation of a specific system in a specific environment, as documented in the certification report.

(My) CISSP Notes – Information Security Governance and Risk Management

Adrian Citu1 Comment

Note: This notes were made using the following books: “CISPP Study Guide” and “CISSP for dummies”.
The Information Security Governance and Risk Management domain focuses on risk analysis and mitigation. This domain also details security governance, or the organizational structure required for a successful information security program.

CIA triad

  •  Confidentiality seeks to prevent the unauthorized disclosure of information. In other words, confidentiality seeks to prevent unauthorized read access to data.
  • Integrity seeks to prevent unauthorized modification of information. In other words, integrity seeks to prevent unauthorized write.
  • Availability ensures that information is available when needed.

The CIA triad may also be described by its opposite: Disclosure, Alteration, and Destruction (DAD).

The term “AAA” is often used, describing cornerstone concepts Authentication, Authorization, and Accountability.

  • Authorization describes the actions you can perform on a system once you have identified and authenticated.
  • Accountability holds users accountable for their actions. This is typically done by logging and analyzing audit data
  • Nonrepudiation means a user cannot deny (repudiate) having performed a transaction. It combines authentication and integrity: nonrepudiation authenticates the identity of a user who performs a transaction, and ensures the integrity of that transaction. You must have both authentication and integrity to have nonrepudiation.

Least privilege means users should be granted the minimum amount of access (authorization) required to do their jobs, but no more.

Need to know is more granular than least privilege: the user must need to know that specific piece of information before accessing it.

Defense-in-Depth (also called layered defenses) applies multiple safeguards (also called controls: measures taken to reduce risk) to protect an asset.

Risk analysis

  • Assets are valuable resources you are trying to protect.
  • A threat is a potentially harmful occurrence, like an earthquake, a power outage, or a network-based worm. A threat is a negative action that may harm a system.
  • A vulnerability is a weakness that allows a threat to cause harm.

Risk = Threat × Vulnerability

To have risk, a threat must connect to a vulnerability.

The “Risk = Threat × Vulnerability” equation sometimes uses an added variable called impact: “Risk = Threat × Vulnerability × Impact.”

Impact is the severity of the damage, sometimes expressed in dollars.

Loss of human life has near-infinite impact on the exam. When calculating risk using the “Risk = Threat × Vulnerability × Impact” formula, any risk involving loss of human life is extremely high, and must be mitigated.

The Annualized Loss Expectancy (ALE) calculation allows you to determine the annual cost of a loss due to a risk. Once calculated, ALE allows you to make informed decisions to mitigate the risk.

The Asset value (AV) is the value of the asset you are trying to protect.

PII = Personally Identifiable Information

The Exposure Factor (EF) is the percentage of value an asset lost due to an incident.

The Single Loss Expectancy (SLE) is the cost of a single loss. SLE  = AV x EF.

The Annual Rate of Occurrence (ARO) is the number of losses you suffer per year.

The Annualized Loss Expectancy (ALE) is your yearly cost due to a risk. It is calculated by multiplying the Single Loss Expectancy (SLE) times the Annual Rate of Occurrence (ARO).

The Total Cost of Ownership (TCO) is the total cost of a mitigating safeguard. TCO combines upfront costs (often a one-time capital expense) plus annual cost of maintenance, including staff hours, vendor maintenance fees, software subscriptions, etc.

The Return on Investment (ROI) is the amount of money saved by implementing a safeguard.

Risk Choices

Once we have assessed risk, we must decide what to do. Options include accepting the risk, mitigating or eliminating the risk, transferring the risk, and avoiding the risk.

Quantitative and Qualitative Risk Analysis are two methods for analyzing risk. Quantitative Risk Analysis uses hard metrics, such as dollars. Qualitative Risk Analysis uses simple approximate values. Quantitative is more objective; qualitative is more subjective.

The risk management process

Risk Management Guide for Information Technology Systems (see http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf).

The guide describes a 9-step Risk Analysis process:

1. System Characterization – System characterization describes the scope of the risk management effort and the systems that will be analyzed.

2. Threat Identification –

Threat Identification and Vulnerability Identification, identify the threats and vulnerabilities, required to identify risks using the “Risk = Threat × Vulnerability” formula.

3. Vulnerability Identification

4. Control Analysis – Control Analysis, analyzes the security controls (safeguards) that are in place or planned to mitigate risk.

5. Likelihood Determination

6. Impact Analysis

7. Risk Determination

8. Control Recommendations

9. Results Documentation

Information Security Governance

Information Security Governance is information security at the organizational level.

Security Policy and related documents

  • Policies are high-level management directives. Policy is high level: it does not delve into specifics. All policy should contain these basic components: Purpose, Scope, Responsibilities , Compliance.  NIST Special Publication 800-12 (see http://csrc.nist.gov/publications/nistpubs/800-12/800-12-html/chapter5.html) discusses three specific policy types: program policy, issue-specific policy, and system-specific policy. Program policy establishes an organization’s information security program.
  • A procedure is a step-by-step guide for accomplishing a task. They are low level and specific. Like policies, procedures are mandatory.
  • A standard describes the specific use of technology, often applied to hardware and software. Standards are mandatory. They lower the Total Cost of Ownership of a safeguard. Standards also support disaster recovery.
  • Guidelines are recommendations (which are discretionary).
  • Baselines are uniform ways of implementing a safeguard.

Roles and responsibilities

Primary information security roles include senior management, data owner, custodian, and user.

  • Senior Managementcreates the information security program and ensures that is properly staffed, funded, and has organizational priority. It is responsible for ensuring that all organizational assets are protected.
  • The Data Owner (also called information owner or business owner) is a management employee responsible for ensuring that specific data is protected. Data owners determine data sensitivity labels and the frequency of data backup. The Data Owner (capital “O”) is responsible for ensuring that data is protected. A user who “owns” data (lower case “o”) has read/write access to objects.
  • A Custodian provides hands-on protection of assets such as data. They perform data backups and restoration, patch systems, configure antivirus software, etc. The Custodians follow detailed orders; they do not make critical decisions on how data is protected.
  • Users must follow the rules: they must comply with mandatory policies procedures, standards, etc.

Complying with laws and regulations is a top information security management priority: both in the real world and on the exam.

The exam will hold you to a very high standard in regard to compliance with laws and regulations. We are not expected to know the law as well as a lawyer, but we are expected to know when to call a lawyer.

The most legally correct answer is often the best for the exam.

Privacy is the protection of the confidentiality of personal information.

Due care and Due Diligence

Due care is doing what a reasonable person would do. It is sometimes called the “prudent man” rule. The term derives from “duty of care”: parents have a duty to care for their children, for example. Due diligence is the management of due care.

Due care is informal; due diligence follows a process.

Gross negligence is the opposite of due care. It is a legally important concept. If you suffer loss of PII, but can demonstrate due care in protecting the PII, you are on legally stronger ground, for example.

Auditing and Control Frameworks

Auditing means verifying compliance to a security control framework (or published specification).

A number of control frameworks are available to assist auditing Risk Analysis. Some, such as PCI (Payment Card Industry), are industry-specific (vendors who use credit cards in the example). Others, such as OCTAVE, ISO 17799/27002, and COBIT.

OCTAVE stands for Operationally Critical Threat, Asset, and Vulnerability Evaluation, a risk management framework from Carnegie Mellon University. OCTAVE describes a three-phase process for managing risk. Phase 1 identifies staff knowledge, assets, and threats. Phase 2 identifies vulnerabilities and evaluates safeguards. Phase 3 conducts the Risk Analysis and develops the risk mitigation strategy. OCTAVE is a high-quality free resource which may be downloaded from: http://www.cert.org/octave/ ISO 17799 and the ISO 27000 Series.

ISO 17799 had 11 areas, focusing on specific information security controls:

1. Policy

2. Organization of information security

3. Asset management

4. Human resources security

5. Physical and environmental security

6. Communications and operations management

7. Access control

8. Information systems acquisition, development, and maintenance

9. Information security incident management

10. Business continuity management

11. Compliance3 ISO 17799 was renumbered to ISO 27002 in 2005, to make it consistent with the 27000 series of ISO security standards.

Simply put, ISO 27002 describes information security best practices (Techniques), and ISO 27001 describes a process for auditing (requirements) those best practices.

COBIT (Control Objectives for Information and related Technology) is a control framework for employing information security governance best practices within an organization.  COBIT was developed by ISACA (Information Systems Audit and Control Association.

ITIL(Information Technology Infrastructure Library) is a framework for providing best services in IT Service Management (ITSM). ITIL contains five “Service Management Practices—Core Guidance” publications: • Service Strategy • Service Design • Service Transition • Service Operation • Continual Service Improvement

Certification and Accreditation

Certification is a detailed inspection that verifies whether a system meets the documented security requirements.

Accreditation is the Data Owner’s acceptance of the risk represented by that system.

Security certifications for programmers

Adrian Citu

This blog entry starts from a very simple question : “What a programmer need to know about the security in order to write more secure code ?” I know that IT security is a very vast topic but in my case I’m interested only in “application security”.  My goal was to find some certifications that will teach me the basics of the “applications security”. You may wonder why I chose to look for the certifications, why not “normal” trainings.  I choose to look for the certifications because I supposed and hoped that will provide me an objective measure of knowledge, skills and abilities.

So here are the security certifications for programmers:

What I like about these certifications is that it gives you all the necessary informations before passing the exams but on the other side I was not convinced about the  previews offered on the site.

What I like about GSSP is that are different exams for different languages since the security risks are not the same for all the programming languages. What I don’t like (beside the price) is the missing of a study guide.

  • Certified Secure Software Lifecycle Professional(CSSLP) The process of certification is quite difficult: must provide proof of four years in the Systems Development Life Cycle (SDLC) process or 3 years plus a bachelors degree or regional equivalent in an IT discipline, submit Experience Assessment essays or pass examination, complete the endorsement process. The certification is focused on security of the following SDLCs: Systems Development Life Cycle, Secure Software Requirements, Secure Software Design, Secure Software Implementation, Secure Software Testing, Software Acceptance, Software Deployment. The price of the exam is $650 USD and the recertification is required every three years under the following conditions : earn 90 Continuing Professional Education (CPE) credits (minimum 15 CPEs earned each year) and pay annual maintenance fees ($100 USD). In case you need a study guide you can take a look at this book The CSSLP Prep Guide: Mastering the Certified Secure Software Lifecycle Professional (not released yet).
  • EC-Council Certified Secure Programmer (ECSP) In order to be an ECSP you must pass an exam ($250). Associated training is available  (online training). On the site EC-Council offer very often free courses consisting in only one day. If you do not take the associated training from the EC-Council, you must complete an eligibility form before you can take the exam and for recertification each member must achieve 120 credits within 3 years and clock in 20 credits per year.
  • EC-Council Certified Secure Application Developer (CSAD) The CSAD is a ECSP + application development certification (for Linux: LCE / LCA / RHCE / LPI certification, for Microsoft: MCAD / MCSD / MCTS / MCPD certification, for Sun:  SCJD / SCEA certification, for Oracle: OCP certification ( DBA), for IBM: Websphere certification)

Passing the SCEA 5 (III) Section 4.1

Adrian Citu

What are EJB’s

Enterprise beans are Java EE components that implement Enterprise JavaBeans (EJB) technology. Enterprise beans run in the EJB container, a runtime environment within the Application Server.
An EJB is essentially a managed component that is created, controlled, and destroyed by the JEE container in which it lives. This control allows the container to control the number of EJBs currently in existence and the resources they are using, such as memory and database connections. Each container will maintain a pool of EJB instances that are ready to be assigned to a client.

When a client no longer needs an EJB, the EJB instance will be returned to the pool and all of its resources will be released. At times of heavy load, even EJB instances that are still in use by clients will be returned to the pool so they can service other clients. When the original client makes another request of its EJB, the container will reconstitute the original EJB instance to service the request. This pooling and recycling of EJB instances means that a few EJB instances, and the resources they use, can be shared between many clients.This maximizes the scalability of the EJB-based application.

There are two different types of EJB that are suited to different purposes:

  • Session EJB—A Session EJB is useful for mapping business process flow (or equivalent application concepts). There are two sub-types of Session EJB — stateless and stateful. Session EJBs commonly represent “pure” functionality that is created as it is needed.
  • Message-driven EJB—A Message-driven EJB is very similar in concept to a Session EJB, but is only activated when an asynchronous message arrives.

As an application designer, you should choose the most appropriate type of EJB based on the task to be accomplished.
Entity EJB are not part of EJB 3.0 but now are part of JP (Java Persistence) API

Common Uses of EJB’s

So, given all of this, where would you commonly encounter EJBs and in what roles? Well, the following are some examples:

  • In a Web-centric application, the EJBs will provide the business logic that sits behind the Web-oriented components, such as servlets and JSPs. If a Web-oriented application requires a high level of scalability or maintainability, use of EJBs can help to deliver this.
  • Thick client applications, such as Swing applications, will use EJBs in a similar way to Web-centric applications. To share business logic in a natural way between different types of client applications, EJBs can be used to house that business logic.
  • Business-to-business (B2B) e-commerce applications can also take advantage of EJBs. Because B2B e-commerce frequently revolves around the integration of business processes, EJBs provide an ideal place to house the business process logic. They can also provide a link between the Web technologies frequently used to deliver B2B and the business systems behind.
  • Enterprise Application Integration (EAI) applications can incorporate EJBs to house processing and mapping between different applications. Again, this is an encapsulation of the business logic that is needed when transferring data between applications (in this case, in-house applications).

When to use Enterprise Beans

You should consider using enterprise beans if your application has any of the following requirements:

  • The application must be scalable. To accommodate a growing number of users, you may need to distribute an application’s components across multiple machines. Not only can the enterprise beans of an application run on different machines, but also their location will remain transparent to the clients.
  • Transactions must ensure data integrity. Enterprise beans support transactions, the mechanisms that manage the concurrent access of shared objects.
  • The application will have a variety of clients. With only a few lines of code, remote clients can easily locate enterprise beans. These clients can be thin, various, and numerous.

Entity Beans

Starting from JEE5 the entity beans have been replaced by Java Persistence API entities. The entities are used to view in an object oriented way o persistent store. In the real world the persistent stores are always relational databases. Typically an entity represents a table in a relational database, and each entity instance corresponds to a row in that table.

Advantages:

  • It can run outside of a JEE container.
  • Offers a object oriented view of a data base.
  • Declaratively transactional support (only if the entity is managed by a Java EE compliant container) Verify This !
  • Declaratively security support (only if the entity is managed by a Java EE compliant container) Verify This !
  • Transaction aware (only if the entity is managed by a Java EE compliant container) Verify This !

Disadvantages: Dig on this !

Stateless Session Beans

A session bean represents a single client inside the Application Server. To access an application that is deployed on the server, the client invokes the session bean’s methods. The session bean performs work for its client, shielding the client from complexity by executing business tasks inside the server.

As its name suggests, a session bean is similar to an interactive session. A session bean is not shared; it can have only one client, in the same way that an interactive session can have only one user. Like an interactive session, a session bean is not persistent. (That is, its data is not saved to a database.) When the client terminates, its session bean appears to terminate and is no longer associated with the client.
A stateless session bean does not maintain a conversational state with the client. When a client invokes the methods of a stateless bean, the bean’s instance variables may contain a state specific to that client, but only for the duration of the invocation.


The life cycle of a stateless session bean

Advantages:

  • Scalability because stateless session beans can support multiple clients. Typically, an application requires fewer stateless session beans than stateful session beans to support the same number of clients. The instances can be pooled by the container.
  • A stateless session bean can implement a web service, but other types of enterprise beans cannot.
  • Declaratively transactional support
  • Declaratively security support
  • Portability
  • Transaction aware

Disadvantages:

  • Need a JEE container to be executed (the Entity beans can be executed outside a JEE container). Find better than this !

Stateful Session Beans

The state of an object consists of the values of its instance variables. In a stateful session bean, the instance variables represent the state of a unique client-bean session. Because the client interacts (“talks”) with its bean, this state is often called the conversational state.

The state is retained for the duration of the client-bean session. If the client removes the bean or terminates, the session ends and the state disappears.

The life cycle of a stateful session bean

Advantages:

  • Declaratively transactional support
  • Declaratively security support
  • Portability
  • Transaction aware

Disadvantages:

  • Need a JEE container to be executed (the Entity beans can be executed outside a JEE container) Find better than this !

Message Driven Beans

A message-driven bean is an enterprise bean that allows Java EE applications to process messages asynchronously. It normally acts as a JMS message listener, which is similar to an event listener except that it receives JMS messages instead of events. The messages can be sent by any Java EE component (an application client, another enterprise bean, or a web component) or by a JMS application or system that does not use Java EE technology. Message-driven beans can process JMS messages or other kinds of messages.

The Life Cycle of a Message-Driven Bean

Advantages:

  • Scalabity; A message-driven bean’s instances retain no data or conversational state for a specific client. The instances can be pooled by the container.
  • Simplicity; Unlike a session bean, a message-driven bean has only a bean class.
  • Loose coupling between the client and the server; The client have no direct reference to the MDB
  • Declaratively transactional support
  • Declaratively security support
  • Portability
  • Transaction aware
  • Firewall issues; in some organizations the ports used by JMS can be closed.
  • Need a JEE container to be executed (the Entity beans can be executed outside a JEE container). Find better than this !

Bibliography:

The Java EE 5 Tutorial


Introduction to EJBs

Passing the SCEA 5 (II) Section 8.1

Adrian Citu

Java Security Architecture

Main Concepts :

  • Protection Domain ( java.security.ProtectionDomain )

A fundamental concept and important building block of system security is the protection domain . A domain can be scoped by the set of objects that are currently directly accessible by a principal, where a principal is an entity in the computer system to which permissions are granted.

The protection domain concept serves as a convenient mechanism for grouping and isolation between units of protection. For example, it is possible (but not yet provided as a built-in feature) to separate protection domains from interacting with each other so that any permitted interaction must be either through trusted system code or explicitly allowed by the domains concerned.

Protection domains generally fall into two distinct categories: system domain and application domain.
It is important that all protected external resources, such as the file system, the networking facility, and the screen and keyboard, be accessible only via system domains.

A domain conceptually encloses a set of classes whose instances are granted the same set of permissions. Protection domains are determined by the policy currently in effect. The Java application environment maintains a mapping from code (classes and instances) to their protection domains and then to their permissions, as illustrated by the figure below.

  • Permissions ( java.security.Permission )

The permission classes represent access to system resources. In essence, permissions determine whether access to a resource of the JVM is granted or denied. The java.security.Permission class is an abstract class and is subclassed, as appropriate, to represent specific accesses.

An applet or an application using a security manager can obtain access to a system resource only if it has permission.

Commonly used permissions :

1. java.security.Permission This abstract class is the ancestor of all permissions. It defines the essential functionalities required for all permissions.
2. java.security.BasicPermission The BasicPermission class extends the Permission class. It can be used as the base class for permissions that want to follow the same naming convention as BasicPermission.
3. java.security.Permissions This class is designed to hold a heterogeneous collection of permissions. Basically, it is a collection of java.security.PermissionCollection objects.
4. java.io.FilePermission
5. java.net.SocketPermission This class represents access to a network via sockets.
6. java.util.PropertyPermission
7. java.lang.RuntimePermission
8. java.awt.AWTPermission

  • Policy (java.security.Policy)

The Java 2 security policy defines the protection domains for all running Java code with access privileges and a set of permissions such as read and write access or making a connection to a host.

The system security policy for a Java application environment, specifying which permissions are available for code from various sources, is represented by a Policy object. More specifically, it is represented by a Policy subclass providing an implementation of the abstract methods in the Policy class.

In order for an applet (or an application running under a SecurityManager) to be allowed to perform secured actions, such as reading or writing a file, the applet (or application) must be granted permission for that particular action.

In the Policy reference implementation, the policy can be specified within one or more policy configuration files. The configuration files indicate what permissions are allowed for code from specified code sources. Each configuration file must be encoded in UTF-8.

A user or an administrator externally configures the policy file for a J2SE runtime environment using an ASCII text file or a serialized binary file representing a Policy class. In a J2SE environment, the default system-wide security policy file java.policy is located at <JRE_HOME>/lib/security/ directory. The policy file location is defined in the security properties file with a java.security setting, which is located at <JRE_HOME>/lib/security/java.security.

Examples of policies :

The following policy grants permission a.b.Foo to code signed by Roland:

grant signedBy "Roland" {
permission a.b.Foo;
};

The following grants a FilePermission to all code (regardless of the signer and/or codeBase):

grant {
permission java.io.FilePermission ".tmp", "read";
};

The following grants two permissions to code that is signed by both Li and Roland:

grant signedBy "Roland,Li" {
permission java.io.FilePermission "/tmp/*", "read";
permission java.util.PropertyPermission "user.*";
};

The following grants two permissions to code that is signed by Li and that comes from http://java.sun.com:

grant codeBase "http://java.sun.com/*", signedBy "Li" {
permission java.io.FilePermission "/tmp/*", "read";
permission java.io.SocketPermission "*", "connect";
};

The following grants two permissions to code that is signed by both Li and Roland, and only if the bytecodes implementing com.abc.TVPermission are genuinely signed by Li.

grant signedBy "Roland,Li" {
permission java.io.FilePermission "/tmp/*", "read";
permission com.abc.TVPermission "channel-5", "watch",
signedBy "Li";
};

  • Access Controller (java.security.AccessController)

The AccessController class is used for three purposes :

1. to decide whether an access to a critical system resource is to be allowed or denied, based on the security policy currently in effect,
2. to mark code as being “privileged”, thus affecting subsequent access determinations.
3. to obtain a “snapshot” of the current calling context so access-control decisions from a different context can be made with respect to the saved context.

  • SecurityManager ( java.lang.SecurityManager )

Each Java application can have its own security manager that acts as its primary security guard against malicious attacks. The security manager enforces the required security policy of an application by performing runtime checks and authorizing access, thereby protecting resources from malicious operations.
Under the hood, it uses the Java security policy file to decide which set of permissions are granted to the classes. However, when untrusted classes and third-party applications use the JVM, the Java security manager applies the security policy associated with the JVM to identify malicious operations. In many cases, where the threat model does not include malicious code being run in the JVM, the Java security manager is unnecessary. In cases where the SecurityManager detects a security policy violation, the JVM will throw an AccessControlException or a SecurityException.

In a Java application, the security manager is set by the setSecurityManager method in class System. And the current security manager is obtained via the getSecurityManager method.

If you wish to have your applications use a SecurityManager and security policy, start up the JVM with the -Djava.security.manager option and you can also specify a security policy file using the policies in the -Djava.security.policy option as JVM arguments. If you enable the Java Security Manager in your application but do not specify a security policy file, then the Java Security Manager uses the default security policies defined in the java.policy file in the $JAVA_HOME/jre/lib/security directory.

  • SecurityManager versus AccessController

To understand the relationship between SecurityManager and AccessController, it is sufficient to note that SecurityManager represents the concept of a central point of access control, while AccessController implements a particular access control algorithm, with special features such as the doPrivileged method. By keeping SecurityManager up to date, we maintain backward compatibility (e.g., for those applications that have written their own security manager classes based on earlier versions of the JDK) and flexibility (e.g., for someone wanting to customize the security model to implement mandatory access control or multilevel security). By providing AccessController, we build in the algorithm that we believe is the most restrictive and that relieves the typical programmer from the burden of having to write extensive security code in most scenarios.

We encourage the use of AccessController in application code, while customization of a security manager (via subclassing) should be the last resort and should be done with extreme care. Moreover, a customized security manager, such as one that always checks the time of the day before invoking standard security checks, could and should utilize the algorithm provided by AccessController whenever appropriate.

Java Applet Security

Currently, all Java 2 SDK system code invokes SecurityManager methods to check the policy currently in effect and perform access control checks. There is typically a security manager (SecurityManager implementation) installed whenever an applet is running; the appletviewer and most browsers, including those from Netscape and Microsoft, install a security manager.

A security manager is not automatically installed when an application is running. To apply the same security policy to an application found on the local file system as to downloaded applets, either the user running the application must invoke the Java Virtual Machine with the new “-Djava.security.manager” command-line argument (which sets the value of the java.security.manager property), as in

java -Djava.security.manager SomeApp

or the application itself must call the setSecurityManager method in the java.lang.System class to install a security manager.

It is possible to specify on the command line a particular security manager to be utilized, by following “-Djava.security.manager” with an equals and the name of the class to be used as the security manager, as in

java -Djava.security.manager=COM.abc.MySecMgr SomeApp

Trusted applets

An applet can be considered trusted, based on the following factors:

1. Applets installed on a local filesystem or executed on a localhost.
2. Signed applets provide a way to verify that the applet is downloaded from a reliable source and can be trusted to run with the permissions granted in the policy file.

The Java 2 platform requires an executable applet class to be packaged into a JAR file before it is signed. The JAR file is signed using the private key of the applet creator. The signature is verified using its public key by the client user of the JAR file. The public key certificate is sent along with the JAR file to any client recipients who will use the applet. The client who receives the certificate uses it to authenticate the signature on the JAR file. To sign the applet, we need to obtain a certificate that is capable of code signing. For all production purposes, you must always obtain a certificate from a CA such as VeriSign, Thawte, or some other CA.

A trusted applet is executed as a normal application (it follows the policy file).

Untrusted applets

Here is a list of the security restrictions that Java 2 technology environments normally impose on applets running in a browser:
1. An applet can utilize only its own code and is not allowed to load libraries or define native methods.
2. An applet cannot read or write files on the host that is executing it.
3. An applet can make network connections only to the host from which it was downloaded.
4. An applet cannot start any program on the local host.
5. An applet is restricted from reading the following system properties: java.home, java.classpath, user.name, user.dir, user.home

Java WebStart Security

When you launch one of the applications shown in the Java WebStart desktop, the classes needed to run that application are downloaded from the Web server.
This behavior is similar to that of an applet. However, once downloaded, the classes are stored locally. This allows for a faster startup on subsequent uses of the application. Better yet, each time you try to run that application, the system checks to see if any updates are available
on the Web server, and if any updates exist, just the needed changes are downloaded. This ensures that the application is always ready to run, even if your computer is not connected to the network, while also ensuring that the most up-to-date version possible is used. All this occurs with no need for an installation phase.

JWS also allows defining security attributes for client-side Java applications and their access to local resources, such as file system access, making network connections, and so on. These security attributes are specified using XML tags in the JNLP descriptor file.

The JNLP descriptor defines the application access privileges to the local and network resources. In addition, JWS allows the use of digital signatures for signing JAR files in order to verify the application origin and its integrity so that it can be trusted before it is downloaded to a client machine. The certificate used to sign the JAR files is verified using the trusted certificates in the client keystore. This helps users avoid starting malicious applications and inadvertent downloads without knowing the originating source of the application.

When running an application that requests unrestricted access to the local machine, the user will be initially presented with a dialog that explains the origin of the application or vendor and allows the user to grant additional privileges to the application. Furthermore, when an application requires the use of a local machine’s resources and does not have a signed JAR file, Java Web Start will allow the user to explicitly grant the application the access via a Security Advisory dialog. For example, if a client Java application needed to be able to paste information into the Windows OS clipboard facility, a dialog box similar to the one shown in the next figure would appear.


Security Advisory dialog for application attempting to access the clipboard

Additional dialog windows will appear when an application attempts to access the local resources of a client machine, such as the filesystem, as displayed in the next figure.


Security Advisory dialog for application attempting to access the filesystem

Users can grant applications access to the local machine in the following areas:

1. Storing the current state of the application on the local machine
2. Viewing the contents of local files
3. Saving files to the local machine
4. Opening files to the local machine
5. Reading/writing to random access files on the local machine
6. Printing from the local machine

JNPL file

The root element is tagged as <jnlp>, which contains the four core sub-elements: information, security, resources, and application-desc.

To enforce security, the <security> element is used to specify the required permissions. The security element provides two permission options: <all-permissions/> to provide an application with full access to the client’s local computing resources, and <j2ee-application-client-permissions/> to provide a selected set of permissions that includes socket permissions, clipboard access permission, printing permission, and so forth. Example 3-19 is a JNLP file that shows putting all the elements including a <security> element setting with all permissions.
Example of JNLP file showing <security> elements

<?xml version="1.0" encoding="UTF-8"?>
<jnlp spec="1.0+" codebase="file:///c:/testarea/jnlp/">
<information>
<title>My Signed Jar</title>
<vendor>Core Security Patterns</vendor>
<homepage href="http://www.sec-patterns.com/signed" />
<description>Java Web start example</description>
</information>
<offline-allowed/>
<security>
<all-permission/>
</security>
<resources>
<j2se version="1.2+" />
<jar href="SignedClientApp.jar"/>
</resources>
<application-desc main-class="SignedClientApp" />
</jnlp

Bibliography:

Mikalai Zaikin SCEA 5 study guide
Java Web Start
Java Security Management Tools
JavaTM Web Start version 1.5.0 – Frequently Asked Questions (FAQ)
JavaTM 2 Platform Security Architecture (V 1.2)