Domain 3. Secure Software Design

Security Design Concepts

• Least Privileged: min privilege in min time necessary for operation
• Separation of Duties (Compartmentalisation): single task dependent upon two or more conditions
• Defence in Depth: single points of compromise eliminated by multiple layers of countermeasures
• Fail Secure: maintain CIA by defaulting to a secure state on failure
• Economy of Mechanisms: reduce attackability using Keep It Simple principle
• Complete Mediation: access is mediated each time, every time and cannot be bypassed or circumvented
• Open Design: implementation and design are independent, knowing the design should not result in the compromise
• Least Common Mechanisms: disallows sharing of common mechanisms to user / process at different privilege level
• Psycological Acceptability: maximizing adoption of security through ease of use and transparency
• Weakest Link: resiliency depends on the protection of the weakest components
• Leveraging Existing Components: reuse components to avoid introducing new attack surface

The Need for Secure Design

• Benefits of designing security early in SDLC:
  • Resilient and recoverable software
  • Quality, maintainable software that is less prone to errors
  • Minimal redesign and consistency
  • Identify business logic flaws
• Flaws & Bugs:
  • Flaws: design and architectural defects that can result in errors.
    • Flaws are broad classes of vulnerabilities
    • Syntactic: syntax errors
    • Semantic: logic errors
    • Countermeasures:
      • Architecture review
      • Design review
      • Attack surface evaluation
      • Threat modelling
      • Misuse modelling
  • Bugs: coding/implementation constructs that can cause a security breach.
    • A bug can be specific or architectural:
      • e.g insufficient input validation, improper error and session management
    • Countermeasure:
      • Architecture review
      • Code Review
      • Pen-test

Architecting Software with Core Security Concepts

Confidentiality

• During design
  • Determine elements that need to be secured
  • Determine what state they are in
  • Determine authorised parties
• Cryptographic and masking: protect against disclosure
  • Cryptographic: data in transit and at rest
    • Overt: encryption, hashing
      • Hashing can be deterministic (same input, same digest) or non-deterministic
    • Covert: steganography, digital watermarking
  • Masking: data displayed on screen, printed forms
    • Masking doesn’t use any overt crypto (encryption/decryption, hashing) or covert operations (steganography)
• Cryptanalysis: the science of finding vulnerabilities in cryptographic protection mechanisms
  • Goal: ensure attacker’s effort (work factor) is huge, makes subversion/evasion impossible, deterrent
    • Work factor: attacker’s effort to breach, depend on key size
    • Key: a sequence of symbols that controls the encryption and decryption operations of a cryptographic algorithm
    • Key size: the length of the key used in the algorithm
  • Pne-time pad: an algorithm that is provably unbreakable by brute-force attacks
    • Key must be truely random
    • Key must be discarded after use
    • Key size equals to message size
• Key management life cycle:
  • Generation
  • Exchange
  • Storage: access control needed when stored in config file or hardware security modules
  • Rotation:
    • Expiration for current key
    • Generation, exchange and storage for new key
  • Archiving
  • Destruction
• Symmetric Algorithms
  • Same key for encryption/decryption
  • Advantages: fast, efficient for large volumn in a short period of time
  • Disadvantages:
    • Key exchange and Management
    • Scalability: complexity n(n-1)/2
    • Non-repudiation not provided

• Asymmetric Algorithms
  • Consist of a public and private key pair
  • Should be computationally infeasible to derive the private key from the public key
  • Provides Confidentiality and Non-repudiation
  • Other benefits:
    • Access control: private key is limited to one person
    • Authentication: the identity of the sender is validated
    • Integrity assurance: unless key pair lost, otherwise cannot decrypt and modify
  • Advantages:
    • Easier Key exchange and Management
      • Public Key Infrastructure, through digital certificates
    • Scalability: 2n
    • Non-repudiation
  • Disadvantages:
    • Computationally intensive
  • Examples:
    • RSA
    • El Gamal
    • Diffie-Hellman: used only for key exchange and not data encryption
    • Elliptic Curve Cryptosystem (ECC): ideal for small, hardware devices, e.g smart cards, mobile
• Digital Certificates
  • Current standard: ITU X.509 version 3 (X.509 v3)
  • Can be used to verify the authenticity of the certificate: contains certificate of the CA
  • Structure:
    • Required:
      • Certificate: Version, Algorithm, Serial Number
      • Issuer: CA
      • Valid period
      • Subject: Name, Public Key: Algorithm, Value
    • Optional:
      • Unique ID: Issuer, Subject
      • Extensions: additional certificate and policy information
  • Types of digital certificates
    • Personal: identify individuals and authenticate them with the server, e.g S-Mime
    • Server: identify servers, e.g TLS
    • Extended Validation: improve user confidence and reduce Phishing attack threats
      • Traditionally certificates only protect communication between server and client
      • EV also provide assurance on the legitimaty of the resource
      • Undergoes more extensive validation on owner identity before issued, addresses MITM
    • Software Publisher: sign software distributed on the Internet
      • Does not assure the signed code is safe for execution, only informing it’s signed by a trusted software publisher’s CA
• Digital Signatures
  • Certificates holds digital signatures of the CAs that verified and issued the digital certificates
  • Provides identity verification, integrity and non-repudiation

Integrity

• Protecting data from unauthorized alteration (e.g altered, deleted)
  • Control the access, e.g Access Control
  • Detemining if data has been altered, e.g Hashing
• Hashing
  • Important to ensure collision free
  • Birthday attack: brute force, two random people may have the same birthday
  • Dictionary attack: brute force using an exhaustive list
  • Salting: a mechanism to assure collision free, prevent pre-built dictionary
  • Department of Homeland Security considers MD family as cryptographically broken, move to SHA

• Referential Integrity
  • Normalization
  • Atomic operation
  • Ensure data is not left in an orphaned state
  • Cascading deletes: when referer is deleted, all refered items are also deleted
  • Cascading updates: when parent changes, all subsequent records are also updated
• Resource Locking
  • No two concurrent operations allowed on the same object until one finishes
  • Deadlock: two operations waiting for each other to release the resource lock

Availability Design

• A system being available to authorized users when appropriate
  • Define what aspects need availability protection and what aspects are not sensitive
  • Business Impact Analysis (BIA) can be used to determine the requirements
  • The key is in determining the specifics of the availability need and expressing them in a requirement
• Backups, Data Replication
• Replication:
  • Single point of failure: no redundancy capabilities
  • Master-slave: master populates data, secondary is passive/inactive
  • Active/Active replication: updates made on both at the same time
  • Active/Passive replication: uddate made on master, replicated to slave
  • Need to take care of data integrity
• Failover:
  • Automatic switching from an active system to a standby (or redundant) system
  • Failover vs switchover: failover is automatic, switchover is manual
  • In HA, need to identify and address all single point of failures
• Scalability
  • The ability to handle increasing (or growing) amount of work without degradation in its functionality or performance:
  • Each copy of software/system is referred as a node
  • Vertical scaling (also known as Scaling Up): more resource added to the node, i.e, db connection pool
  • Horizontal scaling (also known as Scaling Out): more nodes are created
    • caching improved performance, but need to be carefully designed to prevent disclosure and integrity issues
    • should consider TTL setting for cache

Authentication

• The process used to verify one’s claim of identity.
  • Key question: the level of assurance needed with respect to authentication.
• Whenever possible, leave authentication to established systems
• Consider SSO and multi-factor authentication

Authorization

• The process used to verify one’s claim of access to a resource.
  • More complex than authentication, can be difficult to implement correctly
  • Whenever possible, utilising existing capabilities in established systems
  • RBAC is common in most apps
    • Make sure no conflicting roles that circumvent SoD
• Attention needed on:
  • Performance
  • Separation of duty
  • Least privilege
• Entitlement management: gives granular access control
  • Authorization as a shared service: e.g micro services, cloud
  • Authorization as a built-in component: e.g mobile
  • Benefits:
    • Centralised access control
    • Cross platforms
  • Risk: centralise risk at the entitlement service

Accountability

• The function of measuring specific activities.
• Basic rules:
  • Include error trapping for debugging
  • Protect logs
  • Not to expose sensitive data in the log
    • If need to log sensitive data, encrypt it
• Minimum requirement: who, what, where, when
• Should not contradict external audit regulations with log retention
• Protect the log and ensure it’s admissible in court (e.g hashing)
• Preferrably to use built-in timestamp, rather than self defined

Architecting Software

• Common software security issues:
  • Improper implementation of least privilege
  • Software fails insecurely
  • Authentication mechanisms are easily bypassed
  • Security through obscurity
  • Improper error handling
  • Weak input validation
• Pay attention to critical foundational elements:
  • Configuration management
  • Exception management
  • Session management
• Notes:
  • Attack surface analysis and threat model provide information as to the elements that need to be secured.
  • Legacy code could be designed without secure SDLC, hence should be reviewed; all code should receive the same scrutiny.
• Interconnectivity: software, devices
  • Session Management
    • The management of the communication channel itself on a conversation basis
    • Session management is the use of controls to secure a channel on a conversation-by-conversation basis
    • Individual communications should be separately encrypted so cross-party disclosures do not occur
    • Major design consideration: where to employ these methods
      • Overemployment can make a system unnecessarily complex
      • Underemployment leaves a system open to hijacking
  • Exception Management
    • The management of errors and the recording of critical information for troubleshooting efforts
    • Consider the process of failures and communications associated with them
    • Failures should be anticipated, and planned response mechanisms should be part of the overall system design
    • A secure exception management process improves overall usability and security
  • Configuration Management
    • The application of control principles to the actual operational configuration of an application system
    • Configuration aspect of the application needs to be considered from a security point of view
    • e.g: Initialization parameters, connection strings, paths, keys, and other associated variables
• User Interface
  • Clark and Wilson model: access triple model, subject to object access must be mediated via a program
  • Disclosure protection, masking, restrict insider threats
  • Consider interfaces for data access
  • In-band management offers more simplicity in terms of communications
    • Limitation: exposed to the same threats as the communication channel itself
  • Out-of-band management interfaces use a separate communication channel
    • Properly provisioned, out-of-band management allows management even under conditions where the app itself is under attack, Reduce operational risks
    • Disadvantage: separate, secure communication channels need to be designed
  • Creating a separate management interface for security requires additional resources
    • Advantage: interface can be designed to make the best presentation of the material associated with the application
    • Limitation: this information is in isolation and is not naturally integrated with other pertinent security information
  • Integration into the enterprise security management system increases operational efficiency.
• API: allows interoperability
• Security Management Interfaces (SMI): configure and manage the security of the software.
  • In-band interfaces: having a managed agent in computer, management controller communicates with the agent
  • Out-of-Band Interface: when computer turned off or in sleep, admin can access through out-of-band, Lights Out Management (LOM)
    • Available directly on motherboard, remote management card
  • Notes:
    • Avoid remote connectivity and administration, requiring administrators to log on locally
    • Implement data protection in transit, protection measures at transport (e.g., SSL) or network (e.g., IPSec) layer
    • Use least privilege accounts, RBAC and entitlement management services to control access
    • Log and audit access to the SMI
    • The best place for Configurable settings for logging exceptions, auditing and credential management
• Log Interfaces: environments, events, verbosity
  • Should only be appended, not overwritten
  • Shouldn’t design an UI that allows deletion
• Secure Design and Architecture Review
  • Review needs to be conducted after design
    • Take into account:
      • Security policies
      • Target environment
  • Consider design principles
  • Consider network/host level protections

Secure Design Principles

• Good Enough Security
  • Security should be designed to counter the specific security issue at correct level, no excessive security is necessary
• Least Privilege
  • Need-to-know: based on sensitivity level and clearance level
    • Better to have many admins instead of one super user
  • Modular programming: Single Responsibility Principle
    • Cohesive: each module is designed to perform one operation
    • Coupling: degree of dependencies between modules
  • Non-administrative accounts: use data reader/writer to access DB instead of admin
• Separation of Duties
  • All conditions need to be satisfied before operation can be completed
    • eg: splitting keys
  • Separation of roles in dev team: implement, review, deploy separated
• Defense in Depth
  • Breach of a single vulnerability in the software does not result in complete or total compromise
  • Can be used as a deterrent for the curious and non-determined attackers
• Fail Secure
  • Rapidly recoverable into a normal business and secure state when failed, aims at maintaining the resiliency (i.e CIA)
  • Primarily an availability design consideration
  • Implies SD3: secure by design, secure by default, and secure by deployment
• Economy of Mechanisms
  • Keep It Simple Stupid
  • The more complex the design of the software, the more likely there is of vulnerabilities
  • Refer to requirements traceability matrix to identify unnecessary functionalities
  • Bells-and-whistles: unnecessary functionalities
  • Considerations
    • Unnecessary functionality or unneeded security mechanisms should be avoided
    • Strive for simplicity
    • Strive for operational ease of use
• Complete Mediation
  • Access need to be mediated every time so that authority is not circumvented
  • Caching can therefore lead to an increased security risk
  • Identify privileged code paths
• Open Design
  • Security should not be dependent on the secrecy of the design
  • Security through obscurity should be avoided
  • Design of protection mechanisms should be open for scrutiny by members of the community
• Least Common Mechanisms
  • Mechanisms common to more than one user or process are designed not to be shared
• Psychological Acceptability
  • Security mechanisms should be designed to maximize usage, adoption, and automatic application
    • Are easy to use,
    • Do not affect accessibility
    • Are transparent to the user
• Weakest Link
  • Related concept: Single Point of Failure
  • Super user can be a weak link
• Leveraging Existing Components
  • Re-use of existing components rather than writing one’s own
  • Benefits of reuse:
    • Attack surface not increased
    • Increased productivity
• Single Point of Failure
  • A single failure should not result in system-wide failure.

Design Processes

Attack Surface Evaluation

• Measure the exposure in its entry and exit points.
  • A representation of items available to attack, not a representation of quality.
  • Determining the entry and exit points that can lead to exploits.
    • Enumerate through a list of features, assign priority (Attack Bias)
  • The number of modules a program is composed of does not factor directly into attack surface calculations.
• Relative Attack Surface Quotient (RASQ): relative attackability, likely opportunities for attack against software in comparison to a baseline instead of code level bugs.
  • Three measurement dimensions:
    • Targets and enablers: resources attacker can leverage to construct an attack, two kinds: processes and data
      • Identify: number of potential process and data targets and enablers and likely opportunities
    • Channels and protocols: mechanisms allowing communication between two parties
      • Channel: a mean for sender (attacker) to communication with a receiver (target)
        • Message-passing channel and shared-memory channel
      • Protocol: the rule by which information is exchanged
      • Processes: endpoints of the channel
      • Identify: channel types, instances, protocols, processes, access rights
    • Access rights: privileges associated with each resource, i.e CRUD
  • Evaluate weight of each instance of type
    • chtypes = { socket, endpoint, namedpipe, nullsession }
      • weight(s: socket) = 1
      • weight(e: endpoint) = 0.9
      • weight(n: namedpipe) = 0.8
      • weight(n: nullsession) = 0.9
    • pttypes = { service, webhandler, isapi, dynpage }
      • weight(s: service) = 0.4 + default (s) + admin (s)
        • where default (s) = 0.8 if s = default, 0 otherwise
        • admin (s) = 0.9 if s = admin, 0 otherwise
      • weight(w: webhandler) = 1.0
      • weight(i: isapi) = 1.0
      • weight(d: dynpage) = 0.6
    • dttypes = { accounts, files, regkeys, shares, vdirs}
      • weight(a: account) = 0.7 + admin(a) + guest(a)
        • where admin(a) = 0.9 if a ∈ AdminGroup, 0 otherwise
        • guest(a) = 0.9 if a.name = “Guest”, 0 otherwise.
      • weight(f: file) = 0.7 if weakACL(f), 0 otherwise
      • weight(r: regkey) = 0.4 if weakACL(r), 0 otherwise
      • weight(s: share) = 0.9 if weakACL(s), 0 otherwise
      • weight(v: vdir) = 1.0 if v is executable, 0 otherwise
  • RASQ: the sum of independent contributions from a set of channels types, a set of process target types, a set of data target types, a set of process enablers, all subject to the constraints of the access rights relation, A.
    • RASQ = surf_ch + surf_pt + surf_dt + surf_pe
      • surf_ch = channel surface
      • surf_pt = process target surface
      • surf_dt = data target surface
      • surf_pe = process enablers
• Sources:
  • Microsoft list of Attack Surface Elements
  • Known vulnerabilities
  • A list of features
• Attack Surface Minimisation:
  • A form of Least Privilege
  • Determine design baseline
  • Need design effort

Code Reuse

• Old code should be considered in Attack Surface Evaluation and minimisation
• Old code should be subjected to all of the same security steps and tests as new code.

Design and Architecture Technical Review

• Purpose: assess the efficacy of the SDL
  • Primary function of review: ensure security activity is at desired level.
    • If not, should block advancement under the SDL process until it’s properly done.
• Review should cover:
  • Security progress
  • Code walkthroughs
  • Design reviews
  • Examination of the attack surface area
  • Threat modeling documentation
• Effort is required from both development and security team

Threat Modeling

• Goal:
  • Identify security objectives
  • Identify threats and vulnerabilities
• Prerequisites:
  • Clearly defined infosec policies and standards
  • Be aware of compliance and regulatory
  • A clearly defined and mature SDLC process
  • A plan to act on the threat model
• Benefits:
  • Design flaws can be addressed before a single line of code is written
  • Reducing the need to redesign and fix security issues in code at a later time
• Challenges:
  • Time consumming
  • Requires a mature SDLC
  • Requires training
  • Deemed to be not preferential
  • Not directly related to business return

Threat Modeling Process

• Define security objectives
  • Sources:
    • Internal company policies and standards
    • Regulations, compliance and privacy requirements
    • Business and functional requirements
    • Can include both security and privacy
  • Document business’s rationale for:
    • Data collection, storage, usage
    • Legal and regulatory implication
    • Corporate standards
  • Common mistakes
    • Leaving data protection/classification to the dev team
  • Examples:
    • Prevention of data theft
    • Protection of intellectual property
    • Provide high availability
• Model Application Architecture
  • Identify Physical Topology
    • e.g: on-premise, cloud
  • Identify Logical Topology (include logical tiers)
    • Determine components, services, protocols, and ports, developed/configured
    • Identify the identities, determine authentication: basic, SSO etc
  • Identify Human and Non-Human Actors of the System
    • e.g: customers, sales agents, system admins, database admins
  • Identify Data Elements
    • e.g: product information, customer information
  • Generate a Data Access Control Matrix
  • Identify the technologies that will be used in building the application
  • Identify external dependencies
  • Choices: UML, use cases, misuse cases, data flow diagrams
  • Identify process, data stores, data flows, trust boundaries (most important)
    • For large systems, breakdown to scenario-based pieces
  • Document baselines: assumptions, dependencies
• Identify Threats
  • Identify Trust Boundaries: where trust level or privilege changes
  • Identify Entry Points: items that take in user input
  • Identify Exit Points: items that display information from the system
  • Identify Data Flows: a graphical representation of the flow of data, the backend data storage elements, and relationships between the data sources and destinations
  • Identify Privileged Functionality
  • Introduce Mis-Actors: starting point of threat modelling
  • Determine Potential and Applicable Threats
    • Think Like an Attacker:
      • Brainstorming
      • Using Attack Trees: hierarchical tree, with attacker’s objective or type of attack
        • Objective based:
          • Lv1. objective
          • Lv2, methods to achieve it
        • Attack based:
          • Lv1, attack vector
          • Lv2, vulnerability condition
          • Lv3, mitigated condition
      • Can use OWASP top 10, CWE/SANS top 25 as a starting point
    • Use Categorized Threat Lists
      • NSA IAM
      • OCTAVE risk modelling
      • STRIDE
  • Using a threat model (e.g STRIDE) repeatedly at every elements
  • Avoid issues where the application cannot control
    • e.g: sysadmin intentionally violating the system
  • Document the identified threats in a managed approach
• Identify, Prioritize and Implement Controls
  • Priority should be afforded to any security control that exists in the enterprise.
  • controls only reduce risks, not eliminate threats
  • Controls need to align with the corporate
  • Bug bars or bug band: qualitative bands
  • Delphi Ranking: each member states a risk level without being questioned
    • Members with professional expertise facilitate
    • Avoid dominance influence
    • Predefine ranking criteria and a list of identified threats
    • May not provide a complete picture of the risk, should be used with other methods
  • Average Ranking: DREAD, use smaller range, take numeric average, DREAD/5
    • (D)amage Potential
    • (A)ffected Users
    • (R)eproducibility
    • (E)xploitability
    • (D)iscoverability
    • only gives averaged impact, no insight into the deviation
  • Probability x Impact (P x I) Ranking
    • Risk = (Rvalue + Evalue + DIvalue) X (Dvalue + Avalue)
    • Gives insight to both probability and impact
    • Better to see where the mitigation effort should be allocated
  • Mitigation types:
    • Redesign to eliminate vulnerability
      • Better if early in the SDLC
    • Apply a standard mitigation
      • Advantages:
        • Known to be effective
        • Applicable to many vulnerable points
    • Invent a new mitigation
      • Riskier and more costly
    • Accept the vulnerability
      • Least desirable
  • Threat model and mitigation are dynamic
  • Using Attack Tree
    • Putting attack objective as the root node
    • Putting attack paths as leaves joint using logic gates
  • Risk evaluation:
    • Risk, Impact, Likelihood
    • DREAD model
• Document and Validate
  • Allocate security gates at each SDLC stage for validation
  • Purpose:
    • Assess the quality of threats and mitigations
    • Communicate essential information across the development team
    • Threat: validate the contextual relevance of impact
    • Mitigation: validate the contextual relavance to threats
  • Document all dependencies, assumptions
    • Diagrammatic documentation provides a context for the threats
    • Textual documentation allows for more detailed documentation of each threat
  • Threat doc:
    • Type of threat
    • ID
    • Description
    • Threat target
    • Attack techniques
    • Impact
    • Likelihood
  • Control doc:
    • ID
    • Description
    • Controls to implement
  • Validations:
    • The application architecture that is modeled (diagrammed) is accurate and contextually current (up-to-date).
    • The threats are identified across each trust boundary and for data element.
    • Each threat has been explicitly considered and controls for mitigation, acceptance or avoidance have been identified and mapped to the threats they address.
    • If the threat is being accepted, then the residual risk of that threat should be determined and formally accepted by the business owner.

Threat Sources/Agents

• Human:
  • Ignorant User
  • Accidental Discoverer
  • Curious Attacker
  • Script Kiddies
  • Insider
  • Organized Cybercriminals
  • Third Party/Supplier
• Malware:
  • Proliferative
    • Virus: infect program or host for their malicious operations
    • Worm: does not require the infected victim to survive
  • Stealthware: exploiting weaknesses in the operating system
    • Spyware: harvest sensitive and private information
    • Adware: redirecting users to marketing displays
    • Trojan horse: appear to be innocuous, carry malicious payload, covert channel, e.g bot
    • Rootkit: a set of programs allow maintaining to root access
      • Might be deployed on purpose for law enforcement purpose
      • Blended threats: show characteristics of two or more kinds of malware, e.g rootkit
  • Ransomeware
• Advanced Persistent Threats: leverages both human and non-human, attacks that exploit the target over a long period of time undetected, while the threat agent (malware) is in the victim’s computing environment

Architectures

• Open Systems Interconnect (OSI), ISO/IEC 7498-1:1994
• Benefits:
  • Protection against architecture (flaws) and implementation (bugs)
  • Common security solutions across the enterprise
  • Interoperability
  • Better and quicker security decisions
  • Leveraging best practices
    • e.g OWASP Enterprise Security Application Programming Interface (ESAPI)
    • https://www.owasp.org/index.php/ESAPI_Secure_Coding_Guideline

Distributed Computing

• Client/Server
  • Thin v.s thick client
  • N-Tier architecture
    • 1-tier: spaghetti code, unstracutred code mixed
    • 2-tier: client and server, changes are difficult (i.e all-or-nothing), hard to maintain and scale
    • 3-tier: presentation, business, data
      • Independent changes
      • Encapsulates internal markup, contract-based interafaces between tiers
      • Multiple points of failure
  • Cloud is an extreme case of n-tier model, SaaS, PaaS, IaaS
  • Major risk: Client-side exploits
• Peer-to-Peer
  • Each program has ability to act as a peer, management is not centralised, but uniformly spread among the resources.
    • e.g: file sharing, instant messaging
  • Considerations needed:
    • Channel security: SSL, IPSec
    • Data confidentiality/integrity: cryptography, hashing
    • Call stack/flow security: check at various points
    • Security zone: trust boundaries

Message Queuing

• Challenges in messaging:
  • Throughput
  • Delivery
• MQ uses intermediate server that mediates transmission and delivery
  • Guarantee delivery
  • Logging
  • Security of data flow

Service Oriented Architecture (SOA)

• Distributed, modular applications that are platform neutral and have automated interfaces
• Characteristics:
  • Platform Neutrality
  • Interoperability
  • Modularity and Reusability
  • Abstracted business functionality
  • Contract-Based interfaces (abstracted implementation)
  • Discoverability
• Technologies:
  • Remote Procedure Call (RPC), older
  • Component Object Model (COM), older
  • Distributed Component Object Model (DCOM), older
  • Common Object Request Broker Architecture (CORBA), older
  • Enterprise Service Bus (ESB)
  • Web services (WS)
  • REST
  • Java: Java Remote Method Invocation API
  • Microsoft: Windows Communication Foundation (WCF)

Enterprise Service Bus (ESB)

• A specific form of SOA
  • ESB acts as
    • an abstraction layer for interprocess communication services
    • the conduit between all types of protocols
  • Facilitates communication between mutually interacting software applications
    • Enterprise Application Integration (EAI)
    • Asynchronous
  • Often done via a form of message queuing services
  • Key characteristic: the use of a bus-based architecture
  • Allows: XML, EDI, WSDL, REST, DCOM, CORBA
• Services provided by ESB:
  • Protocol conversion, communication transformation
  • Handling defined events
  • MQ and data flow mapping
• Benefits:
  • Security control can be centrally implemented
  • ESB can act as the reference monitor
  • Supports complete mediation
• Mediate modules exmaple:
  • Authentication modules that can leverage directory services
  • Authorization modules that can leverage access management software and services
  • Logging modules that can be used to log message that are input into and output from the ESB.
  • Availability modules that monitor capacity, network flow, etc.
  • Validation modules that make sure that perform ingress and egress filtering of messages that come into or leave the ESB. It can also be used to guarantee delivery of messages.
  • Cryptographic modules that provided encryption, decryption and hashing services.
• Challenges:
  • single point of failure, suggested to implement defence in depth
  • in ESB architecture, Security Zone and DMZ are usually not separated, suggested to have an external and internal ESB and securely bridged

Web Services (WS)

• A software system designed to support interoperable machine-tomachine interaction over a network
  • Web Services Description Language (WSDL): XML-based interface description language, describes the functionality of a web service.
  • Machine readable description of the interface
  • Provide platform and vendor neutrality
  • Performance and implementation immaturity issues can be introduced
• Originally designed with Simple Object Access Protocol (SOAP), uses XML but without security in mind, now favours REST
• Representational State Transfer (REST)
  • Allow text-based access of web resources in a stateless manner
  • Variant of SOA, a.k.a Resource Oriented Architecture (ROA)
  • RESTful Web service
    • Has a unique Resource Address or Base URI (e.g., http://isc2.org/resources/)
    • Supports media type of the data supported by the Web service (e.g., XML, JSON, etc.)
    • Uses HTTP Methods for its operations (e.g., GET, PUT, POST, or DELETE)
  • Advantages:
    • Platform/language independent
    • Not strongly typed
    • Doesn’t require a message header from service provider
    • Faster
    • No built-in security measures
    • Reduces coupling
• JavaScript Object Notation (JSON), built on two data structures
  • A collection of name/value pairs
  • An ordered list of values
• Universal Description, Discovery and Interface (UDDI)
  • By Organization for the Advancement of Structured Information Standards (OASIS)
  • A universal platform-independent method for enterprises to dynamically discover web services
  • Designed as a protocol-based registry through which services worldwide can list themselves on the Internet
  • Only used inside organisations instead of across the world
• Appropriate applications:
  • Where reliability and speed are not assured (for example, the Internet)
  • Where managing the requestor and provider agents need to be upgraded at once
  • Where the distributed computing components run on different platforms
  • When deployment cannot be managed centrally
  • When products from different vendors need to interoperate
  • When an existing functionality can be wrapped using a contract-based interface and needs to be exposed over the internet
• Considerations
  • Secure Messaging
    • XML Encryption and XML Signature
    • TLS/SSL
  • Resource Protection
    • Services need to be identity-aware
    • Services need to identify and authenticate one another
    • Identification and authentication can be achieved using token-based authentication, the SOAP authentication header, or transport layer authentication
  • Contract Negotiation
    • WSDL: XML based, describe service contracts and allowed operations
    • Need to protect against scanning and enumeration
  • Trust Relationships
    • Pairwise Trust Model: each service is provided a list of other trusted services, not scalable
    • Brokered Trust Model: independent 3rd party provides service information
    • Federated Trust Model: trust established between two separate companies, a pre-definition of contracts, protocols and interfaces is needed. the place that maintains the trust relationship needs to be protected
    • Proxy Trust Model: using perimeter defence devices, can be single point of failure

Rich Internet Applications

• Bring the richness of the desktop environment and software onto the Web, e.g: Facebook and Twitter
  • Frameworks used: AJAX, Abode Flash/Flex/AIR, Microsoft Silverlight, and JavaFX
  • an architecture that can mimic desktop applications in usability and function
• Same Origin Policy:
  • Prevent a resource from one source to interact with resources in another
  • Orgin determined by protocol, host, port (i.e document.domain)
• Sandbox: run within broswer, restricted from accessing system resources unless explicitly granted
• RIA increases attack surface
  • Client-Side Exploits or Threats
  • Remote Code Execution
    • Consequence of the architectural decision in which there is not a distinction between code and data
• Protections:
  • Data encryption and encoding
  • Determine the actual origin, not just the last referrer

Pervasive/Ubiquitous Computing

• Main objective: construct an environment where connectivity is unobtrusive
• Two elements of pervasive computing (ubiquitous computing):
  • Pervasive computation: anything embedded with a chip can be a part of the network
  • Pervasive communication: anything on a pervasive network can communicate with each other
• Pervasive network is heterogeneous in nature
• Trusted Platform Module (TPM) chip on the device is better than Media Access Control (MAC)
• Mobile Device Management (MDM) needs to be considered
  • Required to protect against physical threats, e.g auto-erase
  • Biometric is recommended over PIN-based
• Important design concepts: defence in depth, fail secure, complete mediation
  • Each element needs to be self-sufficient and self-reliant for security, safety and stability

Wireless Networking and Communications

• Most wireless network configurations are with default values
• SSID cloaking: SSID is not broadcast
• The Wired Equivalent Privacy (WEP): 40-bit RC4 stream cipher for cryptographic protection, weak
• Wi-Fi Protected Access (WPA and WPA2) is recommended
• Attacks againt bluetooth: Bluesnarfing, Bluejacking, Bluebugging
• Other attacks:
  • Eavesdropping
  • Traffic analysis
  • Wireless Address Resolution Protocol (ARP) spoofing
  • Disclosure and MITM (spoofing) attacks
  • Message injection or deletion
  • Jamming
• Constant Connectivity: everything is always connected
• Location Based Services (LBS)
  • Geofencing: the triggering of an action as a mobile device crosses a boundary
  • Developers must ensure:
    • User is notified of being potentially tracked
    • User consent is obtained before leveraging location tracking functionality
    • Software should be designed to allow toggle of location tracking
  • Examples:
    • Global Positioning Systems (GPS)
    • Geographic Information Systems (GIS)
    • Network-based Position System
    • Control plane location
    • Global Subscriber Module (GSM)

Radio Frequency Identification (RFID)

• Battery assisted tags (BATs) (Active)
• Magnetic field powered tags (Passive)
• Must ensure:
  • Anonymity: preventing unauthorized identification of users
  • Unlinkability: preventing unauthorized tracing of tags and linking their communication
  • Location privacy: preventing unauthorized access to user-profile data

Near Field Communication (NFC)

• NFC: a wireless short-range communications technology for closerange/contactless transactions
• Threats:
  • Message interception and manipulation
  • Man-in-the-Middle (MITM)
  • Eavesdropping (low possibility due to shortrange)
• Mitigation:
  • Establish a secure channel
  • End-points must be validated for their authenticity

Sensor Networks

• Challenges:
  • Limited power and storage
  • Unreliable connection
  • Physical thefting
• Key considerations:
  • Data disclosure
  • Alteration
  • Time synchronisation
• Most notable threat: availability
• Threats:
  • Node takeovers
  • Addressing (routing) protocol attacks
  • Eavesdropping
  • Traffic analysis
  • Spoofing
  • Sybil attack: a rogue device assumes different identities of a legitimate sensor node
• Best practices:
  • Physical security protections
  • Change default configurations
  • Do not broadcast SSID
  • SSL/TLS
  • Use a shared-secret authentication mechanism to keep rogue devices from hopping onto your network
  • Use device-based authentication for internal application on the network
  • Use biometric authentication for user access to the device, if feasible
  • Disable or remove primitive services, e.g Telnet, FTP
  • Auto-erase capability
  • Regular audit and monitoring

Mainframe Architecture

• Capable of bulk data processing with great computation speed and efficiency
  • Speed meansured in Millions of Instructions Per Second (MIPS)
• Evaluation Assurance Level of 5, highest
• Avoid rewriting applications, mainframe Job Control Language (JCL), and network infrastructure scripts
• Challenge: people skilled in the operational procedures and security reducing

Mobile Applications

Architecture

• Frontend, middleware and backend
  • Thick clients: “rich” clients, business/data layer on the frontend
  • Thin clients: business/data layer on backend
• Components:
  • Client Hardware (Cellular, GPS, Sensor, Touch Screen, Camera, etc.)
  • Client Software (Operating System, VM runtime, Mobile Application, etc.)
  • Interfaces (NFC, RFID, 802.11x, Bluetooth, etc.)
  • Endpoints (App Stores, Web sites/services, Corporate, etc.)
  • Carrier Networks (Voice, Data, SMS, etc.)
  • Data Storage (Local, Cloud, Flash, Removable, etc.) and
  • Data Transmission
• Types:
  • Native apps: installed on the client device
    • Limited to no connectivity to the backend
  • Browser based apps: web based mobile applications
    • Installed on the client device
    • Similar to traditional desktop web applications
  • Rich Internet mobile apps: deployed on the client but leverage the backend
    • A service layer that is usually implemented using SOAP or REST
  • Hybrid apps: blend between native apps and browser based
    • App itself hosts a browser, user interacts with the browser in the native app
• Mobile OS: understand and be familiar with the inherent security capabilities and weaknesses
  • iOS: a multi-tasking feature known as backgrounding, iOS takes a screenshot of the application before minimizing it to run in the background. However, when this occurs, it is important to ensure that no sensitive data that is presented on the screen is captured in the screenshot.

Security in Mobile Applications

• Information Disclosure: predominant security concern
  • Lost or Stolen Devices
    • Important to design in remote wipe
  • Insecure Data Storage in Local or Cloud Databases
    • Mobile local storage not as mature as desktop
    • Cloud, lack of data separation/remanence
    • No sensitive data should be stored unprotected
    • Must not be stored indefinitely
  • Insufficient Protection of Data Transmission
    • Lack of end-to-end/data-in-motion protection
  • Broken Cryptography:
    • Custom cryptography
    • Hardcoding of keys
    • Recommended to use platform provided encryption APIs
    • For key management, secure containers should be used
• Side Channel Data Leakage: sensitive data disclosed from unintended locations
  • e.g web caches, temporary directories, log files, screenshots
  • Threat agents: iOS backgrounding, jail break, keylogging
  • Mitigation:
    • Cache encryption
    • Anti-caching directives
    • Communication channel audits
    • Avoid logging credentials
    • Remove sensitive information before app transition
    • Disable field keystorke logging
    • Debug the app to understand file operations
  • Reverse Engineering (Decompilation, Debugging, Disassembly):
    • Mitigation:
      • Code obfuscation
      • Avoid hardcoding sensitive information
• Mobile DoS/DDoS
  • Transferring tools to mobile is easy:
    • Low Orbit Ion Cannon (LOIC) made into a PUP (Potentially Unwanted Program) easily
  • Taking advantage of Carrier Network
  • e.g, Android.DDoS.1.origin: a malware disguised as a legitimate Google Play app, backend controlled by a hacker, instruction received through SMS, configuration identified and packets sent, crashing the device and flooding the network
  • Push Notification flooding attack/fake update attack
• Broken Authentication
  • Root cause: insecure design and insecure code
  • e.g: basic auth, cleartext password, spoofing of unique IDs.
    • Universally Unique Identifiers (UUIDs)
    • International Mobile Equipment Identification (IMEI), physical device
    • International Mobile Subscriber Identification (IMSI), SIM card
  • Mitigation:
    • Encrypt credentials
    • Layered auth checking
    • Avoid using easily spoofable data as authenticator
    • Re-auth often if needed
    • Complete mediation
    • Do not ingnore certificate validation warnings
• Bypassing Authorization
  • URL crafting to open another app
  • Insecure payment card storage
  • Circumventing licensing check
  • Must modally check permission at input boundaries
• Improper Session Management
  • MITMo: intercept and replay session tokens in the mobile, sometimes leverage malware
  • Mitigation:
    • Data/session protection
    • Least privilege
    • Transaction verification (i.e user receives a unique code through an out-of-band channel to verify the transaction)
    • Avoid using device ID as auth token
    • Implement session token revocation
• Client-Side Injection
  • Unlike the conventional injection flaw, code is submitted to the client, instead of the server
  • Can be thought of as a variant of the Web DOM-based Cross-Site Scripting (XSS)
  • Mitigation:
    • Input validation (primary)
    • Use cloud storage
    • Utilised libraries for input validation
    • Use prepared statements/stored procedures
    • Check runtime errors/exploits
• Jailbreaking and Sideloading
  • Jailbreaking: exploits vulnerabilities in the OS, tampered so that unauthorised apps can be installed, for closed source OS
  • Sideloading: for open source OS, can be done through configuration
  • Risks:
    • Decreased Stability
    • Voided Warranty
    • Bricked Device
    • Lock-Out from official store, Cydia: an alternative to the Apple App Store
  • Loss of trust
  • Should prevent jailbroken device to access infrastructure
  • If need jailbreak, need to change root password
• Mobile Malware
  • SDK simplifies malware making
  • Exploits used to jailbreak can also install rootkit
    • e.g: Ikee worm, Duh malware
  • Trojans can disguise itself
  • Jailbroken devices are more susceptible to attacks

Secure Development Guidelines and Design Principles

• Smartphone Secure Development Guidelines for App Developers: European Network and Information Security Agency (ENISA)
  • Identify/protect sensitive data on the mobile device
  • Handle password credentials securely on the device
  • Ensure sensitive data is protected in transit
  • Implement authentication/authorization and session management correctly
  • Keep the backend APIs and the platform secure
  • Secure data integration with 3rd party services/applications
  • Pay attention to the consent for the collection/use of user’s data.
  • Implement controls to prevent unauthorized access to paid resources (e.g., wallet, SMS, calls)
  • Ensure secure distribution/provisioning of mobile applications
  • Carefully check any runtime interpretation of code for errors

Integration with Existing Architectures

• Façade programming makes integration with existing architecture possible
• Need to determine backward security compatibility

Cloud Computing

• NIST definition: cloud computing is a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.
• Drivers
  • Primary driver: cost savings
  • Interoperability
  • Multi-tenancy
  • Device independence
  • Portable services
  • Measurable usage
• Benefits:
  • Reduced Cost
  • Reduced Time to Market
  • Integrity of Software Versions
• Characteristics:
  • On-demand self-service: provision without provider’s interaction
  • Broad network access: high connectivity
  • Resource Pooling: shared resource pool
  • Rapid Elasticity: dynamically provisioned
  • Measured Service: automatically monitored and charged
• Types of cloud
  • Public cloud: provided to multiple tenants, tenants have little to no control on infrastructure, platform, software
    • Advantages: reduced upfront cost, easy to scale, no maintenance cost
    • Disadvantages: lack of control
    • e.g: Amazon Elastic Cloud Compute service, Google AppEngine, IBM Blue Cloud, Sun Cloud
  • Private cloud: provided to a single tenant, usually internal to a company, managed by the company
    • Advantages: max control over resource
    • Disadvantages: difficult to scale, upfront cost, setup time
  • Community cloud: multi-tenancy for related entities, tenants have common requirements
    • Share the advantages and disadvantages of both public and private cloud
  • Hybrid cloud: combines two or more of the above, assurance mechanism can be granuarly managed
• Service Models
  • Primary service models
    • SaaS: data hosting, software applications
      • a.k.a: web-based software model, on-demand model, hosted software model
      • Distinction to traditional approach: software owned/maintained by publisher
      • Data security is a legitimate issue in SaaS
    • PaaS: operating systems, middleware, runtime
      • A selected collection of elements into a designed solution stack for a specific problem. This may include apps, databases, web services, storage, and other items that are offered as a service.
    • IaaS: networking equipment, storage, servers, virtual machines
      • A form of cloud computing that offers a complete platform as a provisioning solution to a computing need
      • a customer can deploy and operate arbitrary software across a cloud-based platform without worrying about the specifics of the environment
  • Multi-tenancy: one code to serve all customers, centralised administration, centralised responsibility and control

Security in Cloud Computing

• Data Disclosure, Loss and/or Remanence (Primary threat):
  • Including data leakage and loss
  • Data owner is the tenant
  • Data custodian is the provider
  • Ideally, sensitive data shouldn’t be stored in public, community, hybrid cloud. If have to, the data need to be encrypted
  • Cryptographic agility: ensures the algorithm can be easily changed when needed
  • Data remanence when resource re-provisioned to another tenant
    • Need Data Loss Prevention, Media Sanitisation
• Unauthorized Access:
  • Next only to Confidentiality
  • Data to one tenant should not be accessible to another tenant
  • Brewer & Nash (Chinese wall model): no information can flow between parties that result in a conflict of interests
  • SSO needs to be implemented with security in mind
  • Mitigations: ACL and system hardening
• Man-in-the-Middle and Traffic Hijacking:
  • Due to the fact that data owner doesn’t control the infrastructure, platform and software
  • Mitigations: strong password rules/management, secure user/session management
• Insecure and Proprietary API:
  • Understanding the APIs and the dependency chain of the APIs
  • Consider the use of non-standard APIs, avoid vendor dependency/lock-in
  • Perform a ROI analysis before using the APIs
• Service Interruptions:
  • Centralisation introduced a single-point-of-failure
  • Need to understand the SLA, growing data needs, redundancy, backup, max downtime
• Malicious Personnel (Insiders):
  • Should always know the risk profile of the provider: processes, technologies, people, administrative controls
    • Control over financial reporting:
      • Statement on Auditing Standards No. 70 (SAS 70): an audit usually used for control over financial reporting.
        • Being replaced by Statement on Standards for Attestation Engagements (SSAE) No. 16, a.k.a Reporting on Controls at a Service Organization
  • Cloud Control Matrix, by Cloud Security Alliance (CSA):
    • Provide fundamental security principles to guide cloud service providers of the needed controls.
    • Risk based approach to address cloud threats and vulnerabilities
    • Can be used by tenants as a common criteria/framework when assessing cloud providers
  • Mitigation: identity management, auditing, training
  • Useful skills for development staff:
    • Contract negotiation
    • Supplier risk assessment
    • Secure development
    • Secure operation
• Cloud Abuse:
  • Leveraging the cloud for unintended purpose
    • e.g DDoS, propagating malware, piracy, reverse-crypto
  • Mitigation: determine norm and monitor
• Nefarious Use of Shared Computing/Technology Resources:
  • Cloud Security Alliance’s “Top Threats to Cloud Computing”, “Notorious Nine”
  • e.g: cracking and/or malicious software, hypervisor exploits
  • Cloud bursting: private burst to public, make it a hybrid cloud, maybe caused due to workload demand
    • Cloud isolation is used to prevent IP/MAC spoofing
    • Secure communication between public and private clouds
    • Hardening, sandboxing
• Insufficient Due Diligence / Unknown Risk Profile:
  • Must understand the contractual terms, enforcement, liability coverage, risk profile of provider
  • Cloud service provider’s internal working processes should be transparent to the tenant

Challenges

• Primary challenge: enforceability of governance, regulations, compliance and privacy (GRC+P)
  • Shared: assurance responsibilities, liability(more on the tenants)
  • Tenants: appropriate level of controls, effective operation for protection
  • Best practice:
    • Establishing enforceable contracts
    • Periodic assessment
    • Continuous monitoring
    • Conduct verification on the provider’s claims
• Cyberforensics:
  • Collection of physical evidence from cloud virtual environment, due to rapid elasticity
  • No full understanding of infrastructure, content and IDS logs on both the tenant and provider must be taken into account
  • Visualisation of physical/logical data location might be necessary
  • Partnership between government and industry might be needed

Technologies

• Holistic security: security for interconnected systems, people, process, technology
• Security Support Provider Interface (SSPI)/Generic Security Service API (GSSAPI): an implementation of the IETF RFCs 2743 and 2744
  • Abstract authentication calls
  • Support interoperability
  • Include protocols to negotiate the best security protocol (SPNEGO), delegate (Kerberos), securely transmit (SChannel)
  • Protect credentials using hashes (Digest)

Identity Management

• Identity Management (IDM): the combination of policies, processes and technologies for managing digital identity information.
  • Who or what is requesting access?
  • How are they authenticated?
  • What level of access can be granted based on the security policy?
• IDM life cycle:
  • Provisioning:
    • Creation of digital identities
    • Entitlement: the privileges in an application
    • Roles: a set of entitlements
      • Extends RBAC, consolidate individual system entitlements into fewer business roles
  • Management
    • Renaming
    • Addition/Removal of roles, Rights and Privileges
    • Changes in regulatory requirements and policies
    • Auditing access requests
    • Synchronisation of multiple identities for access to multiple systems
    • Maintaining history (important for non-repudiation)
  • De-provisioning
    • Termination Access Control (TAC)
      • Some may require deactivation to be the only option, instead of delete, can pose a threat
      • Deactivated accounts should be archived and maintained offline
    • Companies are required to provide auditable evidence for effective access control
      • SarbanesOxley (SOX) 404 section mandates annual review
    • Access certification: business engagement in reviewing and approving access entitlements
• Common technologies for IDM:
  • Directories: the repository of identities
    • Lightweight Directory Access Protocol (LDAP): replaced X.500 protocol
    • e.g: IBM (Tivoli), Sun ONE, Oracle Internet Directory (OID), Microsoft Active Directory, Novell eDirectory, OpenLDAP, Red Hat Directory Server
  • Metadirectories and Virtual Directories
    • Propagation and Synchronisation of identity changes
    • Simplifies administration
    • Shortfall: no interface, give rise to virtual-directory (provides a service interface)
    • Virtual directories provide more assurance than metadirectories, function as gatekeepers for compliance
    • e.g: Human Resources (HR), Customer Records Management (CRM) systems, Corporate Directory, Microsoft Identity Lifecycle Management
• Identity management reduces risks:
  • Consistently automating, applying and enforcing identification, authentication, and authorization security policies
  • De-provisioning identities to avoid lingering identities past their allowed time
  • Mitigating the possibility of a user or application gaining unauthorized access to privileged resources
  • Supporting regulatory compliance requirements by providing auditing and reporting capabilities
  • Leveraging common security architecture across all applications
• Federated ID systems: allows user to connect through a known system, e.g Facebook login to another system
  • Two main aspects:
    • Relying party (RP)
    • Identity provider (IdP)
  • A trust relationship exists between RP and IdP

OpenID and OAuth

• OpenID: created for federated authentication (authentication)
  • Allow a third party to authenticate your users by using accounts that user already has
    • Enables websites or applications (consumers) to grant access to their own applications by using another service or application (provider) for authentication
  • Can use without pre-arranged IdP-RP trust relationship
  • Define universal identifier
• OAuth: created so that users don’t need to share their passwords with third party applications (authorisation)
  • Pre-arranged IdP-RP trust relationship required
  • Access to key user groups
• Common part:
  • Achieves SSO attribute transfer with trust relationship
  • Access to broad user populations
  • Leverage UX and account-linking best practices
• Difference:
  • OpenID is limited to “this is who I am” assertion
  • OAuth provides an access_token that can be exchanged for any supported assertion via an API

Credential Management

• Process:
  • Generation
  • Storage
  • Synchronisation
  • Reset
  • Revocation
• Password Management
  • Passwords should be complex
  • Passwords should not be hard coded
  • Passwords should be encrypted when stored
  • Remembering password is not a good security practice
  • Ask for old password to reset to a new one
  • Password change synchronisation, e.g SSO
  • Password reset request needs to be validated
  • Passwords should have expiry dates, enforce One-Time Passwords (OTP)
  • Lightweight Directory Access Protocol (LDAP) can be used to enforce policies and manage passwords
• X.509 Credentials
  • X.509: a series of standards associated with the manipulation of certificates used to transfer asymmetric keys between parties in a verifiable manner
  • A digital certificate binds an individual’s identity to a public key
    • Registration Authority (RA): verifies an individual’s identity
    • Certificate Authority (CA): generates digital certificate
  • PKIX: Public-Key Infrastructure (X.509)
  • A secure PKI solution requires
    • CA
    • RA
    • Certificate revocation mechanism
    • Either Certificate Revocation List or Online Certificate Status Protocol
• Certificate Management
  • Can be used for authentication
  • Public Key Infrastructure (PKI)
    • Manages the generation and distribution of public/private key pairs
    • Publishes the public keys as certificates
    • Registration Authority (RA): a verifier for the CA before a digital certificate is issued by the CA to the requestor.
    • Certificate Authority (CA): trusted entity that issues the digital certificate that holds the public key and related information of the subject.
    • Revocation:
      • CA publishes the Certificate Revocation Lists (CRLs) (certificates revoked by the CA)
      • Validite public key of CA (CA has its own certificate, self-signed i.e subject same as authority) against CA’s CRL
  • PKI management:
    • Creation of public/private key pairs
    • Public key certificate creation
    • Private key revocation and listing in CRL when the private key is compromised
    • Storage and archival of keys and certificates
    • Destruction of certificates
  • PKI gives:
    • Inter-company trust
    • Enforcement of restrictions on usage
    • X.509 gives strong authorisation capabilities
      • Privilege Management Infrastructure (PMI):
        • X.509 attribute certificates
        • Attribute authorities
        • Target gateways
        • Authorization policies
      • Can define user access privileges among multiple apps and vendors
• Single Sign On (SSO)
  • SSO usually implemented together with Kerberos and Secure Assertion Markup Language (SAML)
  • Kerberos:
    • User authenticate -> Ticket Granting Server (TGS) gives Ticket Granting Ticket (TGT)
    • User access to app -> TGT to TGS -> TGS returns a ticket specific to app
    • Tickets saved in ticket cache in the local system
    • Can also be used within the same domain of TGS/TGT, primarily used for intranet, easier than SSO in internet
  • SAML (WS-Security specification recommended):
    • Allows auth in one domain and use resources in another
    • Primarily for web-based environments
    • Exchanges authentication and authorisation data, user profile etc
    • Authorisation decisions:
      • SAML tokens are the de-facto means for SOA
      • OASIS eXtensible Access Control Markup Language (XACML) can also be used as an alternative
  • Federation (key concept): extends SSO across enterprises
    • An individual can log into one site and access services at another affiliated site, mainly for convenience
      • Primary objective: user convenience
    • Need legal protection between enterprises
    • Three primary protocols before SAML 2.0
      • OASIS SAML 1.0: B2B
      • Liberty Alliance ID-FF 1.1 and 1.2: B2C
      • Shibboleth: education institutes that required anonymity in feberation
    • Fast Identity Online (FIDO) Alliance:
      • To address the lack of interoperability among strong authentication devices
      • To alleviate the problems of multiple usernames and passwords
      • To develop an open, scalable and interoperable specification with less reliance on passwords
      • Proposed FIDO-enabled BYOD to attest tokens that are discovered dynamically at the end-points
  • SAML 2.0:
    • Open standard for web-based SSO service
    • Reduced complexity, removed protocol negotiation, mapping and translation
  • SSO considerations:
    • Establish trust between entities
    • Single point of failure
    • A source for DoS
    • Deployment and integration cost can be excessive

Flow Control

• Firewalls (network layer firewalls) separate internal/external sub-networks
  • Security policy enforcer at perimeter
  • Limitation: governed by network architecture
  • Packet Filtering (1st gen)
    • Content-based filtering, stateless, check headers but not payloads
    • Commonly implemented using Access Control Lists (ACLs)
    • Independent, scalable, faster, provides little security, defenseless against malware
  • Proxy (2nd gen)
    • Middleman between internal trusted networks and the outside untrusted
    • Don’t allow direct connection between untrusted and trusted systems
  • Stateful (3rd gen)
    • Track dialog, maintain a state and data context
    • Not as resource intensive
    • Usually transparent to the user
  • Application Layer (Trendy)
    • Application Level Firewall uses information gathered at application level to make decisions
    • Intercept data and examine for malicious content
    • Contain/terminate on threat detection, or redirect to honeypot
    • PCI DSS Req 6.6: either have a (web) application firewall or perform application code reviews
• Middleware
  • Facilitate communication/flow between components
  • Counters single point of failure
• Queuing Infrastructure and Technology
  • Prevent network congestion
  • Microsoft Message Queuing (MSMQ)
  • Oracle Advance Queuing (AQ)
  • IBM MQ Series

Auditing (Logging)

• Required by Sarbanes Oxley (SOX), HIPAA and PCI DSS, EOC
• Log location
  • Local: simeple, quick, but implies another log to secure and to integrate
• Incident response usually follows Auditing.
• Examine logs across applications for user events and activities
• Deciding what to log:
  • When and what information is needed
  • When security is needed for the logged information
• Important:
  • Log consolidation
  • Time synchronisation
• Logs need to be protected (stored/in transit), admin/users shouldn’t have access to logs.
• Other relevant controls:
  • Log Management Service (LMS)
  • Intrusion Detection Systems (IDS)
  • Intrusion Protection Systems (IPS)

Syslog

• Syslog is used to describe the protocol/application that receives and sends, as well as the logs
  • IETF-approved protocol for log messaging
  • Provide a UNIX centric format for log transfer
  • Ensure reception and order
  • de facto for linux, no equivalent in Microsoft
  • Protocol: a client/server protocol used to transmit the logs
    • UDP or TCP, transmit in clear text, can be used with TLS
• Weakness:
  • Syslog transmits in clear text, TLS/SSL must be used
  • Integrity protection is necessary
• Syslog-NG (New Generation): open source implementation of syslog
• NIST SP 800-92 provides guidance on Computer Security Log Management and how to use syslog

Application Event Logs

• Detect exploits, mis-behaviour, violation
• Establish performance baseline
• Recommended to log all security events
• Common issue:
  • Event logging is often disables, missing or poorly configured
• Application event logging bare minimum:
  • Security breaches
  • Critical business processes e.g., order processing, password change, etc.
  • Performance metrics e.g., load time, timeouts, etc.
  • Compliance related events

Data Loss Prevention (DLP)

• Data: second only to people
• DLP: the technology that provides egress filtration, prevents data from leaving the network
  • Not allow classified data to be attached or copied
  • Brings mandatory (labeling) and discretionary (based on discretion of the owner) security
  • Tagging: the process of labelling data that is classified with its appropriate level
    • Can be overwhelming, requires planning, strategy and management support
    • Business owner is ultimately responsible
  • Endpoint devices, e.g USB
  • Top breach: emails with sensitive data attached
• DLP through technology:
  • Monitor tagged data, detecting and preventing loss, and remediation
  • Protect gateways (control usually applied here) and channels
  • Uneducated people could breach DLP
• DLP through policy:
  • Mandates shredding
  • Disallow printing and storing in storage devices
• Storage on cloud requires:
  • Cryptography
  • Access control
  • Leakage protection
• DLP solutions common approach:
  • Screen traffic
  • Examine for traffic that meets profile parameters
• Challenges:
  • Detection location is important
  • Visibility into the data

Virtualization

• Divides a physical resource into multiple virtual resources, abstracts resources and produces the physical characters.
  • e.g: VMWare, Microsoft Hyper-V, and Xen
• Platform virtualisation: single physical server to run multiple OS/sessions
• Storage Area Networks (SAN): an example of storage virtualisation
• Benefits:
  • Reduced cost (by consolidating physical resources)
  • Operational flexibility
  • Green computing; reduced power and cooling
  • Easier deployment and administration
  • Improvded portability
  • Isolation of application, data, and platforms
  • Increased agility to scale IT environment and services to the business
• Need to determine security and securability before selecting virtualisation products
  • Argument 1: virtualisation increases security through isolation
  • Argument 2: virtualisation increates attack surface (hypervisor)
• Security considerations
  • Implement all of the security controls as in a physical environment
  • Protect VM and images
  • Patch management for all VM appliances
  • VM jail-breaking protection
  • Inspect inter-VM traffic by IDS and IPS
  • Implement defense-in-depth safeguard controls
  • Control VM sprawl (i.e uncontrolled proliferation of multiple VM instances)
  • VM security management technologies are still immature:
    • VM security API: leverage security functionality and introspection ability within the virtualization products

Intrusion Detection System (IDS)

• Used to detect potential threats and suspicious activities, I/O bound
  • IDS are not firewalls but can be used with one
  • IDS more useful for insider threats
  • When implemented with logging, an IDS can be used to provide audit
• Types:
  • Device
  • NIDS
  • HIDS
• Main challenge: encrypted payload
• Implementation:
  • Signature-based
    • Weakness: new/unknown threats
    • e.g Snort: open-source, signature-based
  • Anomaly-based (behavioral): compare against a baseline
    • Advantage: detect/discover newer threats
  • Rule-based: based on programmed rules, (e.g IF-THEN-ELSE)

Intrusion Prevention System (IPS)

• IDS mostly passvie, some are reactive
• IPS: contain the threats and prevent it from being manifested
  • Essentially a firewall with network/app level filtering
  • When implemented with logging, an IPS can be used to provide auditing capabilities
• e.g blocking further traffic from the source IP address, locking out the account on brute-force

Digital Rights Management (DRM)

• Digital rights management (DRM): technologies employed so that content owners can exert control over the digital content.
  • Objective: protect IP in the digital world
  • Coverage:
    • Copy protection
    • Usage rights
    • Authenticity
    • Integrity
• DRM: protect IP and content usage of digital works using technological controls
  • Forward locking: a liability protection measure against violators who cannot claim ignorance of the consequences of their violating act, e.g FBI warning before a video starts
  • Can be configured to provide useage right, authenticity, integrity
    • e.g sharing file with external, you have no control, but still want to control the use of the file
  • Provides OSI layer 6 (presentation) security: prevent unauthorised user from viewing
  • Assures content authenticity/integrity
  • e.g tie a file to a unique device id so that even if copied, user still cannot use it, iTunes
• Copyright law: deterrent control, against someone who wishes to make a copy of a protected file/resource, cannot prevent
  • Copyright law permits all that which is not forbidden, DRM forbids all that which is not permitted
• Three core entities:
  • Users: can create/use content, can be grated rights over content
  • Content: the protected resource
  • Rights: permissions, constraints, obligations
    • Rights Expression Language (REL), e.g:
      • ccREL An RDF schema used by the Creative Commons project and the GNU project to express their general public license (GPL) in machine-readable form
      • Open Digital Rights Language (ODRL) - generalized, open standard under development that expresses rights using XML.
      • eXtensible rights Markup Language (XrML) - generalized REL that is more abstract than ODRL. XrML is more of a metalanguage that can be used for developing other RELs.
      • MPEG-21 Part 5 of this MPEG standard includes an REL
      • Publishing Requirements for Industry Standard Metadata (PRISM) - Primarily used in B2B, express rights specific to a task and is used for syndication of print media content such as newspapers and magazines.
    • REL can express right, but cannot enforce rights, leave to software to protect
• Challenges:
  • Using hardware property is recommended but may cause DoS when the hardware is replaced.
    • Tying rights to a person alleviates this concern, but need to ensure the individual’s identity.
  • Using personal data lead to privacy concerns e.g Sony rootkit music CD
  • DRM forbids both illegal and legal copying, affecting Fair Use

Trusted Computing

• Trusted Computing (TC):
  • Technologies developed and promoted by the Trusted Computing Group.
  • Ensure the computer behaves in a consistent and expected manner.
• Trusted Computing Base (TCB): the totality that is critical to its security.
  • TCB is not just a concept, but also creates the foundation for security principles.
• Trusted Platform Module (TPM)
  • Ensure protection against disclosure and implementation of the spec (v1.2, TPM chip)
    • TPM provides generation and tamper-proof storage of cryptographic keys.
    • Can uniquely identify a device
    • Complements smartcards/biometrics
    • Enhanced security against external software and physical attacks
    • Stored information are still vulnerable to disclosure if the requesting software is not secure
      • e.g cold boot side channel attack
  • TPM Features:
    • Hash generator
    • RSA key generator
    • Random Number Generator
    • Encrytion/Decryption Signature Engine
    • Manufacturer’s Key in the storage
• TCG’s Trusted Software Stack (TSS) interface specification: for software design
• Trusted Server specification: for server security
• Trusted Network Connect architecture: for network security
• Mobile Trusted Module: for mobile computing security
• Concerns: TPM could be used to secure a computer from its owner

Anti-Malware

• Malware: software that has malicious intent.
  • Malware requires a vulnerability in a software system to gain its initial infection vector
  • May hide in PDF
• Trustworthiness: a composition of reliability, security and privacy.
• A holistic multi-pronged program should include:
  • The implementation of anti-malware engine (technology)
  • An educated anti-malware research team (people)
  • An update mechanism (process)
• Client-side anti-malware engine: the software that detects, contains and removes the malware.
  • Scanning: monitor different locations on the system, should ensure performance
  • Detection:
    • Two primary techniques:
      • Pattern
      • Behaviour
    • Kernel-mode rootkits
    • Subject Matter Experts (SME): a person who has special skills or knowledge on a particular job or topic.
  • Handling:
    • Quarantine, remove: when handling a rootkit, engine cannot trust the OS, tunnelling signature can help engine to detect inconsistencies and uncover rootkit modifications
    • Restore
• Essential to have a team to focus on malware
  • Anaylysis process:
    • Unpacking
    • Deobfuscating
    • Decrypting
    • Reverse engineering
  • Static analysis: inspects the instructions of the malware to identify and counteract the techniques used in its obfuscation
  • Dynamic analysis: examines the malware behavior by emulating the malware in a VM
    • Polymorphic malware: signature changes everytime it runs
  • Update the singature/malware definition list through a formalise process
• Anti-malware technologies: provides insight into the security state of the computing ecosystem
  • On access protection
  • Real Time protections

Code signing

• The application of digital signature technology to computer code
• Establishes the provider or author of the software
• Deliver information as to the integrity level of the code

Database Security

• Key: define the level of protection needed, not all data have the same level of sensitivity.
• Regulations GLBA, HIPAA, and PCI DSS can impose protection requirements around certain data elements
  • HIPAA and GLBA require protection on stored PII
  • Consequence: willful neglect lead to fines, incarceration of officers, and regulatory oversight
• Attacks:
  • Application layer is a channel for injection attacks
  • Inference attack: confidentiality, steal data through data mining on hidden and trivial info
  • Aggregation attack: non-sensitive information made sensitive when joined together
    • e.g lat/lng + supplies-and-delivery -> army location

Countermeasure

Polyinstantiation

• Multiple instances, visibility determined by user’s clearance level
• Address inference attack by hidding info through classification
• Address aggregation attack by labeling dfifferent aggregations of data separately

Database Encryption

• Initiative: perimeter defenses powerless to protect stored data to internal threats.
• Encryption is a preventive control against disclosure/alteration
• Aspects to consider:
  • Encryption, secure the key
  • Access control
  • Auditing for security
  • Logging of privilege database operations and events
  • Capacity planning:
    • Performance, e.g indexing
    • Padding/truncation issues
    • Data size may increase due to encryption
• Two ways
  • Native Database Management System (DBMS) encryption
    • Transparent Database Encryption (TDE), transparent to application layer
    • Benefit: minimal impact on application, but can impact performance
    • Drawback: inherent weakness in key storage, dependent on the strength of the DBMS protection mechanisms
  • External cryptographic resources
    • Recommended from security standpoint, increases work factor for attacker
    • Keys can be stored in Hardware Security Modules (HSM)
    • Move computation overhead away from DBMS
    • Drawback: need to modify the design and communication
• Primary keys are used for joining tables, hence is not usually encrypted, therefore should not use PII as primary keys

Normalization

• Normalization: a technique used to organize data, remove redundancy and inconsistency.
• Maintainability and security of db are directly proportional to its organization of data
  • Redundant data increases attack surface
• Organisation of data based on rules (a.k.a normal form)
  • Three data organization or normalization rules
    • 1NF: “No Repeating Groups” rule
      • No repeating fields or groups of fields in a table
    • 2NF: “Eliminate Redundant Data” rule
      • Duplicate data are removed
    • 3NF: “Eliminate Non-Key-Dependent Duplicate Data” rule
      • A logical extension of the 2NF and for a table to be in 3NF, must first be in 2NF. Data that are not dependent on the uniquely identifying PK of that table are eliminated and maintained in tables of their own
  • Database design is said to be in the normal form that corresponds to the number of rules the design complies with
• Benefits:
  • Elimination of redundancy and reduction of inconsistency issues
  • Security benefits
  • Data integrity
  • Granular permission control
• Drawback: degraded performance
  • Need to take time to read from multiple tables
  • May need to denormalise a database, a denormalized database is not the same as a database that has never been normalized

Triggers

• A special type of procedure executed upon certain conditions are met, differs in invocation.
  • Regular procedures are explicitly run by user, app, trigger
  • A trigger is run implicitly by db
• Events that run a trigger:
  • Data Manipulation Language (DML), e.g INSERT, UPDATE and DELETE
  • Data Definition Language (DDL) for administration, e.g auditing, regulating db operations
  • Error events (OnError)
  • System events, such as Start, Shutdown, Restart
  • User events, such as Logon, Logoff
• Triggers can be used to:
  • Enforce complex business rules
  • Prevent invalid transactions
  • Ensure referential integrity operations
  • Provide automated, transparent auditing and event-logging capabilities
  • Enforce complex security privileges and rights
  • Synchronise data (accuracy and integrity) across replications
• Drawbacks:
  • Excessive use of trigger may result in overly complex design
  • Triggers are responsive to events, therefore no commit or rollback
  • Interdependency due to cascaded triggers

Views

• A view is dynamically constructed when the query to generate the view is executed
  • Giving different parties different levels of access to the data
  • Customised presentation of data, the output of a query
  • Virtual, no physical storage allocated, only space to hold the query is allocated
  • view can be customised based on user’s privilege, supports need-to-know
  • Can be used to abstract internal db structure, e.g
    • Joined tables
    • Rename columns against reconnaissance
    • Save complex queries
• Operations performed on the view affect the base tables serving the data

Stored Procedures

• Limit access to only specific elements based on the pre-defined rules

Backup and Replication

• Provide improved availability and redundancy

Privilege Management

• A privilege is the right to perform an operation
  • Permissions are granted to users/roles, processes, objects
• With roles, software needs to have Least Privilege and Separation of Duties
  • Not recommended to grant privilege to a user directly

Programming Language Environment

• Managed v.s Unmanaged programming language
  • Using wrappers for unmanaged code, apply defense-in-depth
  • Prefer strongly typed languages
• Need to understand permissible operations on each data type
  • Widening conversion (a.k.a expansion)
    • Loss of precision
  • Narrowing conversion (a.k.a truncation)
    • Loss of information
  • Considerations
    • Proper casting
    • Length/range validation, i.e using regex/maxlength restrictions
    • Exception management

Languages

Compiled language

• Compiling: converting textual source code to instruction code (object code)
• Linking: combining necessary dependencies to executable
  • Static linking: copy all required elements into one executable
    • Advantage: faster, portable
    • Disadvantage: size
  • Dynamic linking: placing names and relative locations of dependencies, resolve at runtime
    • Advantage: less space
    • Disadvantage: missing dependencies, dependency hijack
    • Need careful security thinking for this option
• e.g: COBOL, Fortran, BASIC, Pascal, C, C++ and Visual Basic

Interpreted language

• Instructions are interpreted by a mediator line by line
• Advantage:
  • Faster code change
  • No need for recompiling/relinking
• Disadvantage: Slower execution
• e.g REXX, PostScript, Perl, Ruby, Python

Main types of languages

• Unmanaged: C/C++
  • Code execution directly managed by OS
  • Need to be compiled
  • Memory allocation unmanaged, pointers can be directly controlled
  • Requires routines to handle
    • Memory allocation
    • Check array bounds
    • Handle data type conversions explicitly
    • Force garbage collection
  • Benefit: performance
• Managed: python, javascript, Java (JVM), MS .NET (CLR)
  • Code execution managed by runtime environment
  • Not compiled into native code
  • Memory allocation managed by runtime
  • Time to develop software is relatively shorter
  • Benefits:
    • Sandboxing
    • Garbage collection
    • Index checking
    • Type safe
    • Memory management
    • Multiplatform capability

Compiler Switches

• /GS flag and StackGuard
  • Protect against memory corruption, buffer overflows
  • Prevent malicious execution and untrusted code
  • Executables can detect/mitigate buffer overflow of return address pointer
  • Security cookie allocated before return address post to function load, after exiting, check cookie
• StackGuard: A patch of GNU gcc, detect/defeat stack memory overflow
  • Provide code pointer integrity check
  • Provide return address integrity protection
  • Placing a canary before return address which is checked before executing the return address
    • Attacker can forge a canary in the overflow exploit
    • Prevention
      • Terminator canary: common termination symbols for C standard, when attacker specifies these, execution terminates
      • Random canary: 32-bit random number set on function entry, maintained for the time frame of function call
• /SAFEH: enables a safe exception handling table option that can be checked at run time

Environments

Common Language Runtime (CLR)

• Common Language Runtime (CLR) for .Net, by Microsoft Common Language Infrastructure (CLI)
• Can compiles a range of lanuages into a Common Intermediate Language (CIL, i.e managed code)
• CLR’s Just-In-Time (JIT) compiler transforms CIL into machine instructions
  • Provides memory management, type safety, code access security, garbage collection, exception handling
  • .Net CLR has its own security execution model separated from OS
  • Unlike traditional user-based model, CLR can enforce a policy-based model
    • Code access control: calculate permissions and evidence based on attributes of the code (e.g URL, Site, Application Directory, Zone, Strong name, Publisher, Hash, etc) as oppose to the user

Java Virtual Machine (JVM)

• Java Runtime Environment (JRE), primary component: Java Virtual Machine (JVM)
  • Libraries: Java Package classes
• JVM: an implementation of the Java Machine Specification, important security aspects:
  • Java Class file format
    • Defines the format
    • Mandated to be in this format
  • Java Bytecode language and instruction set
    • Includes instruction sets to perform low level machine operations
  • Class Loader
    • A Java runtime object, load Java classes into the JVM
    • Checks class loaded is not spoofed or redefined
  • Bytecode Verifier (arguably most important component)
    • Called after Class Loader load all classes into JVM
    • Ensure consistency:
      • Class files are in the right format
      • No malicious instructions, gatekeeper
    • If successful, Bytecode is compiled Just-in-Time (JIT) to run
  • Java Security Manager (JSM)
    • If calls native OS, JSM monitors and mediates access, allow/deny
  • Garbage collector
    • Reclaiming unreachable objects in memory

Sandboxing

• Execution of computer code in an environment designed to isolate the code from direct contact with the target system.
• Used to execute untrusted code, code from guests, and unverified programs.

Systems

Operating Systems

• Code Access Security (CAS), prevents code from:
  • Untrustworthy/unknown source from having run time permissions for privileged operations
  • Trusted sources from inadvertently or intentionally compromising security
• Address Space Layout Randomization (ASLR)
  • Due to principle of locality (temporal primarily), programs load the same memory upon each run
  • ASLR a memory manangement technique to protect against memory location discovery
    • Randomise and move the function entry points
    • DLL can load into any of the 256 memory locations, chance to guess is 1/256
  • Available in Windows, Linux
• Data Execution Prevention (DEP)/Executable Space Protection (ESP)
  • Data Execution Prevention (DEP): prevent memory manipulation in an unsafe manner, a.k.a No-Execute (NX)
    • Marks injected data segment as no-execute
    • Can be implemented in hardware or software
  • Executable Space Protection (ESP) is the Unix or Linux equivalent

Embedded Systems

• Increased reliability over a general purpose system
  • Governed by events in real time
  • Tamper resistant sensor
• Standards for embedded system security
  • ISO 15408 (Common Criteria) standard
  • Multiple Independent Levels of Security (MILS) standard
• Attacks:
  • Primarily disclosure attacks
  • Side channel
  • Fault injection
• Control: auto-erase
• Physical deterrent controls:
  • Seals
  • Conformal coatings
  • Tapes
  • Signal physical breach or tampering activities in software
  • Hide critical signals in the internal board layers
• OpenOS, 3rd party apps need to be isolated, limited to access owner’s private data
• TPM chip: can be used for node-to-node authentication, provide tamper resistant storage
• Threat agents are usually more sophisticated than average hackers

Control Systems

• SCADA systems: monitor and control physical processes, primary target for hackers
  • Technologies were mostly proprietary, promoted the security through obscurity
  • Systems were physically secured and disconnected, adoption of open standards make them targets
• SCADA was not originally designed with security in mind
  • Predominant threat: unauthorized access to the control software
  • Packet control protocol is rudimentary or lacking
  • Attacks tend to be overflow/injection types
  • Physical breach by insider
  • Mandates end-to-end authentication and authorization
• Programmable Logic Controller (PLC)
• Remote Terminal Unit (RTU)

Firmware

• Software code held in a device
  • Read-only chips (not programmable by end-user) or flash memory chips
  • Expect future improvement in security
• e.g BIOS

Examples

Design principle

• Defense in Depth
  • Use of input validation along with prepared statements or stored procedures, disallowing dynamic query constructions using user input to defend against injection attacks.
  • Disallowing active scripting in conjunction with output encoding and input or request validation to defend against Cross-Site Scripting (XSS).
  • The use of security zones, which separates the different levels of access according to the zone that the software or person is authorized to access.
• Fail secure
  • The user is denied access by default and the account is locked out after the maximum number (clipping level) of access attempts is tried.
  • Not designing the software to ignore the error and resume next operation.
  • Errors and exceptions are explicitly handled and the error messages are non-verbose in nature. This ensures that system exception information, along with the stack trace, is not bubbled up to the client in raw form, which an attacker can use to determine the internal makeup of the software and launch attacks accordingly to circumvent the security protection mechanisms or take advantage of vulnerabilities in the software. Secure software design will take into account the logging of the error content into a support database and the bubbling up of only a reference value (such as error ID) to the user with instructions to contact the support team for additional support.

Microsoft list of Attack Surface Elements

• Open sockets
• Open remote procedure call (RPC) endpoints
• Open named pipes
• Services
• Services running by default
• Services running as SYSTEM
• Active web handlers (ASP files, HTR files, and so on)
• Active Internet Server Application Programming Interface (ISAPI) filters
• Dynamic webpages (ASP and such)
• Executable virtual directories
• Enabled accounts
• Enabled accounts in admin group
• Null sessions to pipes and shares
• Guest account enabled
• Weak ACLs in the file system
• Weak ACLs in the registry
• Weak ACLs on shares

Database security considerations

• What is the level of risk classification associated with the data?
• What is the usage pattern of the data-how is it protected in transit and in use?
• What is the differing classification across elements of the data-are some more sensitive than others?
• How is encryption being handled in the enterprise for other projects?
• What are the available encryption options to the development team?

Database encryption design questions

• Where the data should be encrypted
• What should be the minimum level of data classification
• Is the database designed to handle data sizes upon encryption?
• Is the business aware of the performance impact?
• Where will the keys used for cryptography operations be stored?
• What authentication and access control measures will be implemented?
• Are the individuals who have access to the database controlled and monitored?
• Are there logging available to prevent insider threats?
• Is there an incident management plan?