Compliance and Regulation for Cybersecurity

What Cybersecurity Challenges do Organizations Face?

Event, attacks, and incidents defied

Security Event An event on a system or network detected by a security device or application.

Security attack A security event that has been identified by correlation and analytics tools as malicious activity that attempting to collect, disrupt, deny, degrade, or destroy information system resources or the information itself.

Security Incident An attack or security event that has been reviewed by security analysts and deemed worthy of deeper investigation.

Security – How to stop “bad guys”

Outsider

• They want to “get-in” – steal data, steal compute time, disrupt legitimate use

• Security baseline ensures we design secure offerings but setting implementation standards

• E.g. Logging, encryption, development, practices, etc.

• Validated through baseline reviews, threat models, penetration testing, etc.

  Inadvertent Actor

• They are “in” – but are human and make mistakes

• Automate procedures to reduce error-technical controls

• Operational/procedural manual process safeguards

• Review logs/reports to find/fix errors. Test automation regularly for accuracy.

  Malicious Insiders

• They are “in” – but are deliberately behaving badly

• Separation of duties – no shared IDs, limit privileged IDs

• Secure coding, logging, monitoring access/operations

Compliance Basics

Security, Privacy, and Compliance

Security

• Designed protection from theft or damage, disruption or misdirection
• Physical controls – for the servers in the data centers
• Technical controls
  • Features and functions of the service (e.g., encryption)
  • What log data is collected?
• Operational controls
  • How a server is configured, updated, monitored, and patched?
  • How staff are trained and what activities they perform?

Privacy

• How information is used, who that information is shared with, or if the information is used to track users?

Compliance

• Tests that security measures are in place.
• Which and how many depend on the specific compliance.
• It Will Often cover additional non-security requirements such as business practices, vendor agreements, organized controls etc.

Compliance: Specific Checklist of Security Controls, Validated

Compliance Basics

Foundational General specifications, (not specific to any industry) important, but generally not legally required. Ex: SOC, ISO.

Industry Specific to an industry, or dealing with a specific type of data. Often legal requirements. Ex: HIPAA, PCI DSS

Any typical compliance process

• General process for any compliance/audit process
  • Scoping
    • “Controls” are based on the goal/compliance – 50–500.
    • Ensure all components in scope are compliant to technical controls.
    • Ensure all processes are compliant to operation controls.
  • Testing and auditing may be:
    • Internal/Self assessments
    • External Audit
  • Audit recertification schedules can be quarterly, bi-quarterly, annually, etc.

Overview of US Cybersecurity Federal Law

Computer Fraud and Abuse Act (CFAA)

• Enacted in 1984

US Federal Laws

• Federal Information Security Management Act of 2002 (FISMA)

• Federal Information Security Modernization Act of 2014 (FISMA 2014)

  FISMA assigns specific responsibilities to federal agencies, the National Institute of Standards and Technology (NIST) and the Office of Management and Budget (OMB) in order to strengthen information security systems.

National Institute of Standards and Technology (NIST) Overview

Cybersecurity and Privacy NIST’s cybersecurity and privacy activities strengthen the security digital environment. NIST’s sustained outreach efforts support the effective application of standards and best practices, enabling the adoption of practical cybersecurity and privacy.

General Data Protection Regulation (GDPR) Overview

This is simply a standard for EU residence:

• Compliance
• Data Protection
• Personal Data: The GDPR cam into effect on 25 May 2018 and represents the biggest change in data privacy in two decades. The legislation aims to give control back to individuals located in EU over their Personal Data and simplify the regulatory environment for internation businesses.

5 Key GDPR Obligations:

1. Rights of EU Data subjects
2. Security of Personal Data
3. Consent
4. Accountability of Compliance
5. Data Protection by Design and by Default

Key terms for understanding

Internation Organization for Standardization (ISO) 2700x

• The ISO 2700 family of standards help organization keep information assets secure.
• ISO/IEC 27001 is the best-known standard in the family providing requirements for an information security management systems (ISMS).
  • The standard provides requirements for establishing, implementing, maintaining and continually improving an information security management system.
• Also becoming more common,
  • ISO 270018 – Privacy
• Other based on industry/application, e.g.,
  • ISO 270017 – Cloud Security
• ISO 27001 Certification can provide credibility to a client of an organization.
• For some industries, certification is a legal or contractual requirement.
• ISO develops the standards but does not issue certifications.
• Organizations that meet the requirements may be certified by an accredited certification body following successful completion of an audit.

System and Organization Controls Report (SOC) Overview

SOC Reports

Why SOC reports?

• Some industry/jurisdictions require SOC2 or local compliance audit.
• Many organizations who know compliance, know SOC Type 2 consider it a stronger statement of operational effectiveness than ISO 27001 (continuous testing).
• Many organization’s clients will accept SOC2 in lieu of the right-to-audit.

Compared with ISO 27001

SOC1 vs SOC2 vs SOC3

SOC1

• Used for situations where the systems are being used for financial reporting.

• Also referenced as Statement on Standards for Attestation Engagements (SSAE)18 AT-C 320 (formerly SSAE 16 or AT 801).

  SOC2

• Addresses a service organization’s controls that are relevant to their operations and compliance, more generally than SOC1.

• Restricted use report contains substantial detail on the system, security practices, testing methodology and results.

• Also, SSAE 18 standards, sections AT-C 105 and AT-C 205.

  SOC3

• General use report to provide interested parties with a CPA’s opinion about same controls in SOC2.

Type 1 vs Type 2

Type 1 Report

• Consider this the starting line.

• The service auditor expresses an opinion on whether the description of the service organization’s systems is fairly presented and whether the controls included in the description are suitably designed to meet the applicable Trust Service criteria as of a point in time.

  Type 2 Report

• Proof you’re maintaining the effectiveness over time

• Typically 6 month, renewed either every 6 months or yearly.

• The service auditor’s report contains the same opinions expressed in a Type 1 report, but also includes an opinion on the operating effectiveness of the service organization’s controls for a period of time. Includes description of the service auditor’s tests of operation effectiveness and test results.

Selecting the appropriate report type

• A type 1 is generally only issued if the service organization’s system has not been in operation for a significant period of time, has recently made significant system or control changes. Or if it is the first year of issuing the report.
• SOC1 and SOC2, each available as Type 1 or Type 2.

Scoping Considerations – SOC 2 Principles

Report scope is defined based on the Trust Service Principles and can be expanded to additional subject.

SOC Reports – Auditor Process Overview

What are auditors looking for:

1) Accuracy → are controls results being assessed for pass/fail. 2) Completeness → do controls implementation cover the entire offering: e.g., no gaps in inventory, personnel, etc. 3) Timeliness → are controls performed on time (or early) with no gaps in coverage. - If a control cannot be performed on time, are there appropriate assessment (risk) approvals BEFORE the control is considered ‘late’. 4) With Resilience notice → are there checks/balances in place such that if a control does fail, would you be able to correct at all? Within a reasonable timeframe? 5) Consistency → Shifting control implementation raises concerns about above, plus increases testing.

What does SOC1/SOC2 Test

General Controls:

• Inventory listing

• HR Employee Listing

• Access group listing

• Access transaction log

  A: Organization and Management

• Organizational Chart

• Vendor Assessments

  B: Communications

• Customer Contracts

• System Description

• Policies and Technical Specifications

  C: Risk Management and Design/Implementation of Controls

• IT Risk Assessment

  D: Monitoring of Controls

• Compliance Testing

• Firewall Monitoring

• Intrusion Detection

• Vulnerability Management

• Access Monitoring

  E: Logical and Physical Access Controls

• Employment Verification

• Continuous Business Need

  F: System Operations

• Incident Management

• Security Incident Management

• Customer Security Incident Management

• Customer Security Incident Reporting

  G: Change Management

• Change Management

• Communication of Changes

  H: Availability

• Capacity Management

• Business Continuity

• Backup or equivalent

Continuous Monitoring – Between audits

Purpose:

• Ensure controls are operating as designed.

• Identify control weaknesses and failure outside an audit setting.

• Communicate results to appropriate stakeholders.

  Scope:

• All production devices

  Controls will be tested for operating effectiveness over time, focusing on:

• Execution against the defined security policies.

• Execution evidence maintenance/availability

• Timely deviation from policy documentation.

• Timely temporary failures of a control or loss of evidence documentation and communication.

Industry Standards

Health Insurance Portability and Accountability Act (HIPAA)

Healthcare organizations use cloud services to achieve more than saving and scalability:

• Foster virtual collaboration across care environments
• Leverage full potential of existing patient data
• Address challenges in analyzing patient needs
• Provide platforms for care innovation
• Expand delivery network
• Reduce response time in the case of emergencies
• Integrate data silos and optimizes information flow
• Increase resource utilization
• Simplify processes, reducing administration cost

What is HIPAA-HITECH

• The US Federal laws and regulations that define the control of most personal healthcare information (PHI) for companies responsible for managing such data are:
  • Health insurance Portability and Accountability Act (HIPAA)
  • Health Information Technology for Economic Clinical Health Act (HITECH)
• The HIPAA Privacy Rule establishes standards to protect individuals’ medical records and other personal health information and applies to health plans, health care clearinghouses, and those health care providers who conduct certain health care transactions electronically.
• The HIPAA Security Rule establishes a set of security standards for protecting certain health information that is held or transferred in electronic form. The Security Rule operationalizes the protections contained in the Privacy Rule by addressing the technical and non-technical safeguards that must be put in place to secure individuals’ “electronic protected health information” (e-PHI)

HIPAA Definitions

U.S. Department of Health and Human Services (HHS) Office of Civil Rights (OCR): Governing entity for HIPAA.

Covered Entity: HHS-OCR define companies that manage healthcare data for their customers as a Covered Entity.

Business Associate: Any vendor company that supports the Covered Entity.

Protected Health Information (PHI): Any information about health status, provision of health care, or payment for health care that is maintained by a Covered Entity (or a Business Associate of a Covered Entity), and can be linked to a specific individual.

HHS-OCR “Wall of Shame”: Breach Portal: Notice to the Secretary of HHS Breach of Unsecured Protected Health Information.

Why is Compliance Essential?

• U.S. Law states that all individuals have the right to expect that their private health information be kept private and only be used to help assure their health.
• There are significant enforcement penalties if a Covered Entity / Business Associate is found in violation.
• HHS-OCR can do unannounced audits on the (CE+BA) or just the BA.

HIPAA is a U.S. Regulation, so be aware…

• Other countries have similar regulations / laws:
  • Canada – Personal Information Protection and Electronic Documents Act
  • European Union (EU) Data Protection Directive (GDPR)
• Many US states address patient privacy issues and are stricter than those set forth in HIPAA and therefore supersedes the US regulations.
• Some international companies will require HIPAA compliance for an either a measure of confidence, or because they intend to do business with US data.

HIPAA Security Rule

The Security Rule requires, covered entities to maintain reasonable and appropriate administrative, technical, and physical safeguards for protecting “electronic protected health information” (e-PHI).

Specifically, covered entities must:

• Ensure the confidentiality, integrity, and availability of all e-PHI they create, receive, maintain or transmit.
• Identify and protect against reasonably anticipated threats to the security or integrity of the information.
• Protect against reasonably anticipated, impermissible uses or disclosures; and
• ensure compliance by their workforce.

Administrative Safeguards

The Administrative Safeguards provision in the Security Rule require covered entities to perform risk analysis as part of their security management processes.

Administrative Safeguards include:

• Security Management Process
• Security Personnel
• Information Access Management
• Workforce Training and Management
• Evaluation

Technical Safeguards

Technical Safeguards include:

• Access Control
• Audit Controls
• Integrity Controls
• Transmission Security

Physical Safeguards

Physical Safeguards include:

• Facility Access and Control
• Workstation and Device Security

Payment Card Industry Data Security Standard (PCI DSS)

The PCI Data Security Standard

• The PCI DSS was introduced in 2004, by American Express, Discover, MasterCard and Visa in response to security breaches and financial losses within the credit card industry.
• Since 2006 the standard has been evolved and maintained by the PCI Security Standards Council, a “global organization, (it) maintains, evolves and promotes Payment Card Industry Standards for the safety of cardholder data across the globe.”
• The PCI Security Standards Council is now comprised of American Express, Discover, JCB International MasterCard and Visa Inc.
• Applies to all entities that store, process, and/or transmit cardholder data.
• Covers technical and operational practices for system components included in or connected to environments with cardholder data.
• PCI DSS 3.2 includes a total of 264 requirements grouped under 12 main requirements.

Goals and Requirements

PCI DSS 3.2 includes a total of 264 requirements grouped under 12 main requirements:

Scope

The Cardholder Data Environment (CDE): People, processes and technology that store, process or transmit cardholder data or sensitive authentication data.

• Cardholder Data:

  • Primary Account Number (PAN)
  • PAN plus any of the following:

    • Cardholder name

    • expiration date and/or service mode.

      Sensitive Authentication Data:

• Security-related information (including but not limited to card validation codes/values, full track data (from the magnetic stripe or equivalent on a chip), PINs, and PIN blocks) used to authenticate cardholder and/or authorize payment card transactions.

  Sensitive Areas:

• Anything that accepts, processes, transmits or stores cardholder data.

• Anything that houses systems that contain cardholder data.

Determining Scope

PCI Requirements

Highlight New and Key requirements:

• Approved Scanning Vendor (ASV) scans (quarterly, external, third party).
• Use PCI scan policy in Nessus for internal vulnerability scans.
• File Integrity Monitoring (FIM)
• Firewall review frequency every 6 months
• Automated logoff of idle session after 15 minutes
• Responsibility Matrix

Critical Security Controls

Center for Internet Security (CIS) Critical Security Controls

CIS Critical Security Controls

• The CIS Controls^TM are a prioritized set of actions that collectively form a defense-in-depth set of best practices that mitigate the most common attacks against systems and networks.
• The CIS Controls^TM are developed by a community of IT experts who apply their first-hand experience as cyber defenders to create these globally accepted security best practices.
• The experts who develop the CIS Controls come from a wide range of sectors including retail, manufacturing, healthcare, education, government, defense, and others.

CIS Control^TM 7

CIS Control^TM 7.1 Implementation Groups

Structure of the CIS Control^TM 7.1

The presentation of each Control in this document includes the following elements:

• A description of the importance of the CIS Control (Why is this control critical?) in blocking or identifying the presence of attacks, and an explanation of how attackers actively exploit the absence of this Control.
• A table of the specific actions (“Sub-Controls”) that organizations should take to implement the Control.
• Procedures and Tools that enable implementation and automation.
• Sample Entity Relationship Diagrams that show components of implementation.

Compliance Summary

Client System Administration Endpoint Protection and Patching

Client System Administration

“The client-server model describes how a server provides resources and services to one or more clients. Examples of servers include web servers, mail servers, and file servers. Each of these servers provide resources to client devices, such as desktop computers, laptops, tablets, and smartphones. Most servers have a one-to-many relationship with clients, meaning a single server can provide resources to multiple clients at one time.”

Client System Administration

• Cloud and Mobile computing
• New Devices, new applications and new services.
• Endpoint devices are the front line of attack.

Common type of Endpoint Attacks

• Spear Phishing/Whale Hunting – An email imitating a trusted source designed to target a specific person or department.
• Watering Hole – Malware placed on a site frequently visited by an employee or group of employees.
• **Ad Network Attacks – Using ad networks to place malware on a machine through ad software.
• Island Hopping – Supply chain infiltration.

Endpoint Protection

Basics of Endpoint Protection

• Endpoint protection management is a policy-based approach to network security that requires endpoint devices to comply with specific criteria before they are granted access to network resources.
• Endpoint security management systems, which can be purchased as software or as a dedicated appliance, discover, manage and control computing devices that request access to the corporate network.
• Endpoint security systems work on a client/server model in which a centrally managed server or gateway hosts the security program and an accompanying client program is installed on each network devices.

Unified Endpoint Management

A UEM platform is one that converges client-based management techniques with Mobile device management (MDM) application programming interfaces (APIs).

Endpoint Detection and Response

Key mitigation capabilities for endpoints

• Deployment of devices with network configurations

• Automatic quarantine/blocking of non-compliant endpoints

• Ability to patch thousands of endpoints at once

  Endpoint Detection and Response

• Automatic policy creation for endpoints

• Zero-day OS updates

• Continuous monitoring, patching, and enforcement of security policies across endpoints.

Examining an Endpoint Security Solution

Three key factors to consider:

1. Threat hunting
2. Detection response
3. User education

An Example of Endpoint Protection

Unified Endpoint Management

UEM is the first step to enable today’s enterprise ecosystem:

• Devices and things
• Apps and content
• People and identity

What is management without insight?

IT and security needs to understand:

• What happened
• What can happen
• What should be done … in the context of their environment

Take a new approach to UEM

UEM with AI

Traditional Client Management Systems

• Involves an agent-based approach
• Great for maintenance and support
• Standardized rinse and repeat process
• Applicable for some OS & servers

Mobile Device Management

• API-based management techniques
• Security and management of corporate mobile assets
• Specialized for over-the-air configuration
• Purpose-built for smartphones and tablets

Modern Unified Endpoint Management

IT Teams are also converging:

Overview of Patching

• All OS require some type of patching.
• Patching is the fundamental and most important thing an organization can do to prevent malicious attacks.

What is a patch?

A patch is a set of changes to a computer program or its supporting data designed to update, fix, or improve it. This includes fixing security vulnerabilities and other bugs, with such patches usually being called bugfixes, or bug fixes, and improving the functionality, usability or performance.

Windows Patching

• Windows Updates allow for fixes to known flaws in Microsoft products and OS. The fixes, known as patches, are modification to software and hardware to help improve performance, reliability, and security.
• Microsoft releases patches in a monthly cycle, commonly referred to as “Patch Tuesday”, the second Tuesday of every month.

Four types of Updates for Windows OSes

1. Security Updates: Security updates for Windows work to protect against new and ongoing threats. They are classified as Critical, Important, Moderate, Low, or non-rated.
2. 590344 These are high priority updates. When these are released, they need to updated asap. It is recommended to have these set as automatic.
3. Software Updates: Software updates are not critical. They often expand features and improve the reliability of the software.
4. Service Packs: These are roll-ups, or a compilation, of all previous updates to ensure that you are up-to-date on all the patches since the release of the product up to a particular data. If your system is behind on updates, then service packs bring your system up-to-update.

Windows Application Patching

Why patch 3^rd party applications in addition to Windows OS?

• Unpatched software, especially if a widely used app like Adobe Flash or Browser, can be a magnet for malware and viruses.
• 87% of the vulnerabilities found in the top 50 programs affected third-party programs such as Adobe Flash and Reader, Java, Skype, Various Media Players, and others outside the Microsoft Ecosystem. That means the remaining 13 percent “stem from OSes and Microsoft Programs,” according to Secunia’s Vulnerability Review report.

Patching Process

Server and User Administration

Introduction to Windows Administration

User and Kernel Modes

MS Windows Components:

• User Mode
  • Private Virtual address space
  • Private handle table
  • Application isolation
• Kernel Mode
  • Single Virtual Address, shared by other kernel processes

File Systems

Types of file systems in Windows

• NTFS (New Technology File system)
• FATxx (File Allocation Table)
  • FAT16, FAT32

Typical Windows Directory Structure

Role-Based Access Control and Permissions

• Access Control Lists (ACLs)
• Principle of the least privileges

Privileged Accounts

• Privileged accounts like admins of Windows services have direct or indirect access to most or all assets in an IT organization.
• Admins will configure Windows to manage access control to provide security for multiple roles and uses.

Access Control

Key concepts that make up access control are:

• Permissions
• Ownership of objects
• Inheritance of permissions
• User rights
• Object auditing

Local User Accounts

Default local user accounts:

• Administrator account

• Guest account

• HelpAssistant account

• DefaultAccount

  Default local system accounts:

• SYSTEM

• Network Service

• Local Service

Management of Local Users accounts and Security Considerations

• Restrict and protect local accounts with administrative rights
• Enforce local account restrictions for remote access
• Deny network logon to all local Administrator accounts
• Create unique passwords for local accounts with administrative rights

What is AD?

Active Directory Domain Services (AD DS) stores information about objects on the network and makes this information easy for administrators and users to find and use.

• Servers
• Volumes
• Printers
• Network user and computer accounts
• Security is integrated with AD through authentication and access control to objects in the directory via policy-based administration.

Features of AD DS

• A set of rules, the schema
• A global catalog
• A query and index mechanism
• A replication service

Active Directory Accounts and Security Considerations

AD Accounts

• Default local accounts in AD:
  • Administrator account
  • Guest Account
  • HelpAssistant Account
  • KRBTGT account (system account)
• Settings for default local accounts in AD
• Manage default local accounts in AD
• Secure and Manage domain controllers

Restrict and Protect sensitive domain accounts

Separate admin accounts from user accounts

• Privileged accounts: Allocate admin accounts to perform the following

  • Minimum: Create separate accounts for domain admins, enterprise admins, or the equivalent with appropriate admin.
  • Better: Create separate accounts for admins that have reduced admin rights, such as accounts for workstation admins, account with user rights over designated AD organizational units (OUs)
  • Ideal: Create multiples, separate accounts for an administrator who has a variety of job responsibilities that require different trust levels

• Standard User account: Grant standard user rights for standard user tasks, such as email, web browsing, and using line-of-business (LOB) applications.

  Create dedicated workstation hosts without Internet and email access

• Admins need to manage job responsibilities that require sensitive admin rights from a dedicated workstation because they don’t have easy physical access to the servers.

  • Minimum: Build dedicated admin workstations and block Internet Access on those workstations, including web browsing and email.

  • Better: Don’t grant admins membership in the local admin group on the computer in order to restrict the admin from bypassing these protections.

  • Ideal: Restrict workstations from having any network connectivity, except for the domain controllers and servers that the administrator accounts are used to manage.

    Restrict administrator logon access to servers and workstations

• It is a best practice to restrict admins from using sensitive admin accounts to sign-in to lower-trust servers and workstations.

• Restrict logon access to lower-trust servers and workstations by using the following guidelines:

  • Minimum: Restrict domain admins from having logon access to servers and workstations. Before starting this procedure, identify all OUs in the domain that contain workstations and servers. Any computers in OUs that are not identified will not restrict admins with sensitive accounts from signing in to them.

  • Better: Restrict domain admins from non-domain controller servers and workstations.

  • Ideal: Restrict server admins from signing in to workstations, in addition to domain admins.

    Disable the account delegation right for administrator accounts

• Although user accounts are not marked for delegation by default, accounts in an AD domain can be trusted for delegation. This means that a service or a computer that is trusted for delegation can impersonate an account that authenticates to the to access other resources across the network.

• It is a best practice to configure the user objects for all sensitive accounts in AD by selecting the Account is sensitive and cannot be delegated check box under Account options to prevent accounts from being delegated.

  

Overview of Server Management with Windows Admin Center

Active Directory Groups

Security groups are used to collect user accounts, computer accounts, and other groups into manageable units.

• For AD, there are two types of admin responsibilities:
  • Server Admins
  • Data Admins
• There are two types of groups in AD:
  • Distribution groups: Used to create email distribution lists.
  • Security groups: Used to assign permissions to shared resources.

Groups scope

Groups are characterized by a scope that identifies the extent to which the group is applied in the domain tree or forest.

The following three group scopes are defined by AD:

• Universal

• Global

• Domain Local

  Default groups, such as the Domain Admins group, are security groups that are created automatically when you create an AD domain. You can use these predefined groups to help control access to shared resources and to delegate specific domain-wide admin roles.

What is Windows Admin Center?

• Windows Admin Center is a new, locally-deployed, browser-based management tool set that lets you manage your Windows Servers with no cloud dependency.
• Windows Admin Center gives you full control over all aspects of your server infrastructure and is useful for managing servers on private networks that not connected to the Internet.

Kerberos Authentication and Logs

Kerberos Authentication

Kerberos is an authentication protocol that is used to verify the identity of a user or host.

• The Kerberos Key Distribution Center (KDC) is integrated with other Windows Server security services and uses the domain’s AD DS database.
• The key Benefits of using Kerberos include:
  • Delegated authentication
  • Single sign on
  • Interoperability
  • More efficient authentication to servers
  • Mutual authentication

Windows Server Logs

• Windows Event Log, the most common location for logs on Windows.
• Windows displays its event logs in the Windows Event Viewer. This application lets you view and navigate the Windows Event Log, search, and filter on particular types of logs, export them for analysis, and more.

Windows Auditing Overview

Audit Policy

• Establishing audit policy is an important facet of security. Monitoring the creation o modification of objects gives you a way to track potential security problems, helps to ensure user accountability, and provides evidence in the event of a security breach.
• There are nine different kinds of events you can audit. If you audit any of those kinds of events, Windows records the events in the Security log, which you can find in the Event Viewer.
  • Account logon Events
  • Account Management
  • Directory service Access
  • Logon Events
  • Object access
  • Policy change
  • Privilege use
  • Process tracking
  • System events

Linux Components: Common Shells

Bash:

The GNU Bourne Again Shell (BASH) is based on the earlier Bourne Again shell for UNIX. On Linux, bash is the most common default shell for user accounts.

Sh:

The Bourne Shell upon which bash is based goes by the name sh. It’s not often used on Linux, often a pointer to the bash shell or other shells.

Tcsh:

This shell is based on the earlier C shell (CSH). Fairly popular, but no major Linux distributions make it the default shell. You don’t assign environment variables the same way in TCSH as in bash.

CSH:

The original C shell isn’t used much on Linux, but if a user is familiar with CSH, TCSh makes a good substitute.

Ksh:

The Korn shell (ksh) was designed to take the best features of the Bourne shell and the C shell and extend them. It has a small but dedicated following among Linux users.

ZSH:

The Z shell (zsh) takes shell evolution further than the Korn shell, incorporating features from earlier shells and adding still more.

Linux Internal and External Commands

Internal Commands:

• Built into the shell program and are shell dependent. Also called built-in commands.
• Determine if a command is a built-in command by using the type command.

External commands:

• Commands that the system offers, are totally shell-independent and usually can be found in any Linux distribution
• They mostly reside in /bin and /usr/bin.

Shell command Tricks:

• Command completion: Type part of a command or a filename (as an option to the command), and then press TAB key.
• Use Ctrl+A or Ctrl+E: To move the cursor to the start or end of the line, respectively.

Samba

Samba is an Open Source/Free software suite that provides seamless file and print services. It uses the TCP/IP protocol that is installed on the host server.

When correctly configured, it allows that host to interact with an MS Windows client or server as if it is a Windows file and print server, so it allows for interoperability between Linux/Unix servers and Windows-based clients.

Cryptography and Compliance Pitfalls

Cryptography Terminology

• Encryption only provides confidentiality, but no integrity.

• Data can be encrypted

  • At rest
  • In use
  • In transit

• Common types of encryption algorithms

  • Symmetric Key (AES, DES, IDEA, …)
  • Public key (RSA, Elliptic Curve, DH, …)

  

Hash Function

Maps data of arbitrary size to data of a fixed size.

• Provides integrity, but not confidentiality
• MD5, SHA-1, SHA-2, SHA-3, and others
• Original data deliberately hard to reconstruct
• Used for integrity checking and sensitive data storage (e.g., passwords)

Digital Signature

“A mathematical scheme for verifying the authenticity of digital messages and documents.”

• Uses hashing and public key encryption
• ensures authentication, non-repudiation, and integrity.

Common Cryptography Pitfalls

Pitfall: Missing Encryption of Data and Communication

• Products handle sensitive business and personal data.

• Data is often the most valuable asset that the business has.

• When you store or transmit it in clear text, it can be easily leaked or stolen.

• In this day and age, there is no excuse for not encrypting data that’s stored or transmitted.

• We have the cryptographic technology that is mature, tested, and is available for all environments and programming languages.

  Encrypt all sensitive data you are handling (and also ensure its integrity).

Pitfall: Missing Encryption of Data and Communication

• Some products owners that we talk to don’t encrypt stored data because “users don’t have access to the file system.”

• There are plenty of vulnerabilities out there that may allow exposure of files stored on the file system.

• The physical machine running the application maybe stolen, the hard disk can be then accessed directly.

  You have to assume that the files containing sensitive information may be exposed and analyzed.

Pitfall: Implementing Your Own Crypto

• Often developers use Base64 encoding, simple xor encoding, and similar obfuscation schemes.

• Also, occasionally we see products implement their own cryptographic algorithms. Please don’t do that!

  Schneier’s Law:

  Anyone, from the most clueless amateur to the best cryptographer, can create an algorithm that he himself can’t break. It’s not even hard. What is hard is creating an algorithm that no one else can break, even after years of analysis.

  Rely on proven cryptography, that was scrutinized by thousands of mathematicians and cryptographers.

• Follow recommendations of NIST.

Pitfall: Relying on Algorithms Being Secret

• We sometimes hear dev teams tell us that “the attacker will never know our internal algorithms.”
  • Bad news – they can and will be discovered; it’s only a question of motivation.
• A whole branch of hacking – Reverse Engineering – is devoted to discovering hidden algorithms and data.
• Even if your application is shipped only in compiled form, it can be “decompiled”.
• Attackers may analyze trial/free versions of the product, or get copies on the Dark Web.
• “Security by obscurity” is not a good defense mechanism.
• The contrary is proven true all the time.

  • All algorithms that keep us safe today are open source and very well-studied: AES, RSA, SHA*, ….

    Always assume that your algorithms will be known to the adversary.

    A great guiding rule is Kerckhoffs’s Principle:

    A cryptosystem should be secure even if everything about the system, except the key, is public knowledge.

Pitfall: Using Hard-coded/Predictable/Weak Keys

• Not safeguarding your keys renders crypto mechanisms useless.

• When the passwords and keys are hard-coded in the product or stored in plaintext in the config file, they can easily be discovered by an attacker.

• An easily guessed key can be found by trying commonly used passwords.

• When keys are generated randomly, they have to be generated from a cryptographically-secure source of randomness, not the regular RNG.

  Rely on hard to guess, randomly generated keys and passwords that are stored securely.

Pitfall: Ignoring Encryption Export Regulation Rules

• Encryption is exported controlled.
• All code that…
  • Contains encryption (closed or open source).
  • Calls encryption algorithms in another library or component.
  • Directs encryption functionality in another product.
• … must be classified for export before being released.

Data Encryption

Encryption Data at rest

• The rule of thumb is to encrypt all sensitive data at rest: in files, config files, databases, backups.
• Symmetric key encryption is most commonly used.
• Follow NIST Guidelines for selecting an appropriate algorithm – currently it’s AES (with CBC mode) and Triple DES.

Pitfalls and Recommendations

• Some algorithms are outdated and no longer considered secure – phase them out
  • examples include DES, RC4, and others.
• Using hard-coded/easily guessed/insufficiently random keys – Select cryptographically-random keys, don’t reuse keys for different installations.
• Storing keys in clear text in proximity to data they protect (“key under the doormat”)
  • stores keys in secure key stores.
• Using initialization vectors (IVs) incorrectly.
  • Use a new random IV every time.
• Preferable to select the biggest key size you can handle (but watch out for export restrictions).

Encryption Data in Use

• Unfortunately, a rarely-followed practice.
• Important, nonetheless, memory could be leaked by an attacker.
  • A famous 2014 Heartbleed defect leaked memory of processes that used OpenSSL.
• The idea is to keep data encrypted up until it must be used.
• Decrypt data as needed, and then promptly erase it in memory after use.
• Keep all sensitive data (data, keys, passwords) encrypted except a brief moment of use.
• Consider Homomorphic encryption if it can be applied to your application.

Encryption Data in Transit

• In this day and age, there is no excuse for communicating in cleartext.
• There is an industry consensus about it; Firefox and Chrome now mark HTTP sites as insecure.
• Attackers can easily snoop on unprotected communication.
• All communications (not just HTTP) should be encrypted, including: RPCs, database connections, and others.
• TLS/SSL is the most commonly used protocol.
  • Public key crypto (e.g., RSA, DH) for authentication and key exchange; Symmetric Key crypto to encrypt the data.
  • Server Digital Certificate references certificate authority (CA) and the public key.
• Sometimes just symmetric key encryption is employed (but requires pre-sharing of keys).

Pitfalls

• Using self-signed certificates
  • Less problematic for internal communications, but still dangerous.
  • Use properly generated certificates verified by established CA.
• Accepting arbitrary certificates
  • Attacker can issue their own certificate and snoop on communications (MitM attacks).
  • Don’t accept arbitrary certificates without verification.
• Not using certificate pinning
  • Attacker may present a properly generated certificate and still snoop on communications.
  • Certificate pinning can help – a presented certificate is checked against a set of expected certificates.
• Using outdated versions of the protocol or insecure cipher suites
  • Old versions of SSL/TLS are vulnerable. (DROWN, POODLE, BEAST, CRIME, BREACH, and other attacks)
  • TLS v1.1-v1.3 are safe to use (v1.2 is recommended, with v1.3 coming)
  • Review your TLS support; there are tools that can help you:
    • Nessus, Qualys SSL Server Test (external only), sslscan, sslyze.
• Allowing TLS downgrade to insecure versions, or even to HTTP
  • Lock down the versions of TLS that you support and don’t allow downgrade; disable HTTP support altogether.
• Not safeguarding private keys
  • Don’t share private keys between different customers, store them in secure key stores.
• Consider implementing Forward Secrecy
  • Some cipher suites protect past sessions against future compromises of secret keys or passwords.
• Don’t use compression under TLS
  • CRIME/BREACH attacks showed that using compression with TLS for changing resources may lead to sensitive data exposure.
• Implement HTTP Strict Transport Security (HSTS)
  • Implement Strict-Transport-Security header on all communications.
• Stay informed of latest security news
  • A protocol or cipher suite that is secure today may be broken in the future.

Hashing Considerations

Hashing

• Hashing is used for a variety of purposes:
  • Validating passwords (salted hashes)
  • Verifying data/code integrity (messages authentication codes and keyed hashes)
  • Verifying data/code integrity and authenticity (digital signatures)
• Use secure hash functions (follow NIST recommendations):
  • SHA-2 (SHA-256, SHA-384, SHA-512, etc.) and SHA-3

Pitfalls: Using Weak or Obsolete Functions

• There are obsolete and broken functions that we still frequently see in the code – phase them out.
• Hash functions for which it is practical to generate collisions (two or more different inputs that correspond to the same hash value) are not considered robust.
• MD5 has been known to be broken for more than 10 years, collisions are fairly easily generated.
• SHA-1 was recently proven to be unreliable.
• Using predictable plaintext
  • Not quite a cryptography problem, but when the plaintext is predictable it can be discovered through brute forcing.
• Using unsalted hashes when validating passwords
  • Even for large issue spaces, rainbow tables can be used to crack hashes.
  • When salt is added to the plaintext, the resulting hash is completely different, and rainbow tables will no longer help.

Additional Considerations

• Use key stretching functions (e.g., PBKDF2) with numerous iterations.
  • Key stretching functions are deliberately slow (controlled by number of iterations) in order to make brute forcing attacks impractical, both online and offline (aim 750ms to complete the operation).
• Future-proof your hashes – include an algorithm identifier, so you can seamlessly upgrade in the future if the current algorithm becomes obsolete.

Message Authentication Codes (MACs)

• MACs confirm that the data block came from the stated sender and hasn’t been changed.

• Hash-based MACs (HMACs) are based on crypto hash functions (e.g., HMAC-SHA256 or HMAC-SHA3).

• They generate a hash of the message with the help of the secret key.

• If the key isn’t known, the attacker can’t alter the message and be able to generate another valid HMAC.

• HMACs help when data may be maliciously altered while under temporary attacker’s control (e.g., cookies, or transmitted messages).

• Even encrypted data should be protected by HMACs (to avoid bit-flipping attacks).

  

Digital Signatures

• Digital signatures ensure that messages and documents come from an authentic source and were not maliciously modified in transit.
• Some recommended uses of digital signatures include verifying integrity of:
  • Data exchanged between nodes in the product.
  • Code transmitted over network for execution at client side (e.g., JavaScript).
  • Service and fix packs installed by customer.
  • Data temporarily saved to customer machine (e.g., backups).
• Digital signatures must be verified to be useful.

Safeguarding Encryption Keys

• Encryption is futile if the encryption keys aren’t safeguarded.
• Don’t store them in your code, in plaintext config files, in databases.
• Proper way to store keys and certificates is in secure cryptographic storage, e.g, keystores
  • For examples, in Java you can use Java Key Store (JKS).
• There is a tricky problem of securing key encrypting key (KEK).
  • This is a key that is used to encrypt the keystore. But how do we secure it?

Securing KEK

• Use hardware secure modules (HSM).
• Use Virtual HSM (Unbound vHSM).
• Derive KEK for user-entered password.
  • An example of this can be seen in Symantec Encryption Desktop Software, securing our laptops.
• Derive KEK from data unique to the machine the product is running on.
  • This could be file system metadata (random file names, file timestamps).
  • An attacker that downloads the database or the keystore will not be able to as easily obtain this information.

Impact of Quantum Computing

• Quantum computing is computing using quantum-mechanical phenomena. Quantum computing may negatively affect cryptographic algorithms we employ today.
• We are still 10–15 years away from quantum computing having an effect on cryptography.
• Risks to existing cryptography:
  • Symmetric encryption (e.g., AES) will be weakened.
    • To maintain current levels of security, double the encryption key size (e.g., got from 128-bit to 256-bit keys).
  • Public key encryption that relies on prime number factorization (e.g., RSA used in SSL/TLS, blockchain, digital signatures) will be broken.
    • Plan on switching to quantum-resistant algorithms – e.g., Lattice-based Cryptography, Homomorphic Encryption.
• Attacker can capture conversations now and decrypt them when quantum computing becomes available.
• General Good practice – make your encryption, hash, signing algorithms “replaceable”, so that you could exchange them for something more robust if a weakness is discovered.