Security Operations

{`
Kelly School of Business
Indiana University
Information Systems Graduate Programs
`}

Themes of Security Operations

  • Maintaining Operational Resilience
  • Protecting Valuable Assets
  • Controlling System Accounts
  • Managing Security Services Effectively

Maintaining Operational Resilience

  • Maintain expected levels of service availability and integrity of critical systems
  • Contingency Planning
  • Fault tolerance
  • Data protection o RAID
    • Database shadowing o Data backups
    • Electronic vaulting
  • Software o Updates
    • Configurations
  • Hardware
    • Hot spares
  • Communications
    • Redundant providers
  • Business Continuity Plan

Protecting Valuable Assets

  • Provide day-to-day protection for human and material assets
  • Tangible vs. intangible assets
  • Tangible assets o Physical assets and hardware o Facilities
    • Media
    • Personnel Safety
  • Intangible assets o Intellectual property
  • Intrusion detection and prevention
  • Boundary controls
  • Data Leak/Loss Prevention (DLP)

Controlling System Accounts

  • Provide checks and balances against privileged accounts
  • Assign specific privileges to various classes of system accounts and monitor them continuously
  • Ordinary user accounts
  • Privileged user accounts o System administrators o Operators o Security administrators o Database administrators

o Application administrators

  • Clearances and background checks
  • Need-to-know/least privilege
  • Separation of duties
  • Job rotation

Managing Security Services

  • Manage day-to-day operations of key security management services
  • Incident Response
  • Change and Configuration Management
  • Patch and Vulnerability Management
  • Problem Management

Patch and Vulnerability Management

  • The main objective of a patch management program is to create a consistently configured environment that is secure against known vulnerabilities in operating systems and application software

Vulnerability Management Systems

  • Vulnerabilities arise from flaws, misconfigurations and policy failures
  • Flaws result from product design imperfections
  • Example: Buffer overflow
  • Misconfigurations represent implementation errors that expose a system to attack
  • Example: Weak access control lists, open ports
  • Policy failures occur when individuals fail to follow or implement security as required Example: Weak passwords, unauthorized network devices
  • Vulnerability scanning
  • Network scan
  • Host-based scan
  • Application security scan

Patch and Vulnerability Management

  • Steps in patch management
  • Identify flaws/vulnerabilities
  • Risk-based decision to determine the necessity of patching the problem
  • Patch prioritization and scheduling
  • Patch testing
  • Patch installation and deployment
  • Change management

 

Patch and Vulnerability Management

  • Sources of vulnerability and patch availability information
  • http://cve.mitre.org
  • http://nvd.nist.gov
  • http://www.us-cert.gov
  • Vendor specific security bulletins

Change Management

  • Change Control Process
  • Requests
  • Impact assessment
  • Approval/disapproval
  • Build and test
  • Notification
  • Implementation
  • Validation
  • Documentation
  • Library maintenance
  • Original copies of all software media must be preserved in a software library for integrity control
  • Patch Management

Configuration Management

  • Configuration management is a process of identifying and documenting hardware components, software, and the associated settings
  • Configuration management provides an organization with knowledge about all of its parts
  • Knowing what composes the system is the first critical step in understanding what is needed to defend it
  • A well-documented environment provides a foundation for sound operations management by ensuring that IT resources are properly deployed and managed

Configuration Management - Hardware

  • A hardware inventory should minimally include:
  • Make
  • Model
  • MAC addresses
  • Serial number
  • Operating system or firmware version
  • Location
  • BIOS and other hardware-related passwords
  • Assigned IP address if applicable
  • Organizational property management label or bar code

Configuration Management - Software

  • A software inventory should minimally include:
  • Software name
  • Software vendor (and reseller if appropriate)
  • Keys or activation codes (note if there are hardware keys)
  • Type of license and for what version
  • Number of licenses
  • License expiration
  • License portability
  • Organizational software librarian or asset manager
  • Organizational contact for installed software
  • Upgrade, full or limited license

Configuration Management Steps

  1. Identify the configuration items, components, and related work products that will be placed under configuration management
  2. Establish and maintain a configuration management and change management system for controlling work products
  3. Create or release baselines for internal use and for delivery to the customer
  4. Track change requests for the configuration items
  5. Control changes in the content of configuration items
  6. Establish and maintain records describing configuration items
  7. Perform configuration audits to maintain the integrity of the configuration baselines

Source: https://www.sei.cmu.edu/productlines/frame_report/config.man.htm

Service Level Agreement (SLA)

  • A SLA is simply a document describing the level of service expected by a customer from a supplier, laying out the metrics by which that service is measured, and the remedies or penalties, if any, should the agreed-upon levels not be achieved
  • Usually, SLAs are between companies and external suppliers, but they may also be between two departments within a company; these are referred to as Operational Level Agreements (OLAs)
  • Few metrics
  • Service availability
  • Defect rates
  • Technical quality
  • Security

Information Security Testing

  • Penetration testing (Ethical hacking, vulnerability testing)
  • Simulate an attack on a system or network at the request of the owner to evaluate risk
  • Usually focused on perimeter systems
  • Must have clearly defined objectives, scope, stated goals, agreed upon limitations and acceptable activities
  • Management oversight is essential to ensure damage does not result

Information Provisioning

  • Zero knowledge
  • Also called black box test
  • Tester is provided no information
  • Partial knowledge
  • Provides limited information
  • Full knowledge
  • All available information is provided

Pen Testing Methodology

  • Reconnaissance/Discovery
  • Enumeration
  • Vulnerability Analysis
  • Exploitation
  • Document Findings

Testing Strategies

  • External vs. Internal testing
  • Blind testing
  • Limited information test. Defenders know that the test is being conducted
  • Double blind testing
  • No information provided. Defenders do not know of test
  • Targeted testing
  • Testers and defenders are aware of all information

Types of Testing

  • Application testing
  • DoS testing
  • War dialing
  • Wireless network testing
  • Social engineering
  • PBX and IP telephony testing

Design Options for Management Architecture

  • Two options
  • Centralized and shared architecture
  • Distributed architecture
  • These options are not mutually exclusive.
  • Most organizations have a combination of centralized, shared, and distributed management tools and processes.

Source: Management Architecture Blueprint , WSSRA, Microsoft Corp.

Design Option 1 Centralized and Shared Management Architecture

  • Designed to facilitate centralized management.
  • Totally centralized management is not always feasible
  • for example, individual geographic divisions or specific business units might require a large amount of control over the management of infrastructure within their domains.
  • Centralized and shared management architectures allow organizations to consolidate and centralize while meeting the particular requirements of operating independent data centers or particular application groups.
  • Also known as shared services architecture
  • This is the ideal architecture though hard to achieve

Source: Management Architecture Blueprint , WSSRA, Microsoft Corp.

Centralized Management Architecture

Centralized Management Architecture

Source: Management Architecture Blueprint , WSSRA, Microsoft Corp.

Design Option 2 Distributed Management Architecture

  • In the distributed model, business units or geographically separated business entities provide management services and processes within the boundaries of their organization.
  • Most organizations still have distributed management processes and technology architectures for management.

Source: Management Architecture Blueprint , WSSRA, Microsoft Corp.

Distributed Management Architecture

Distributed Management Architecture

Source: Management Architecture Blueprint , WSSRA, Microsoft Corp.