Tuesday, December 14, 2021

My AWS re:Invent 2021 Experience

 

The 10th AWS re:Invent conference was held in Las Vegas, NV, on November 28th through December 3rd. The conference included keynote announcements, training and certification opportunities, access to 1,500+ technical sessions, the Expo, and after-hours events, along with all the entertainment Las Vegas has to offer. This event drew visitors from all over the world - 60,000 people attended this year. This post is about my experience at the conference – if you want to read about  all of the announcements AWS made at the event – check out:  https://aws.amazon.com/blogs/aws/top-announcements-of-aws-reinvent-2021/.

PSI brought a small technical team to the conference, just David Nicholls, Zach Melnick, and myself. We’re both experienced cloud engineers interested in learning more about AWS so we can sharpen our skills in cloud operations, security, and development. We spent hours on the Expo floor connecting, interacting with, and learning from AWS builders and partners. We also attended several of the Breakout sessions and Workshops. This event was also a great opportunity to meet with some of our PSI customers at our “Cloud Convo & Cocktails with PSI” event.

Was it worth the trip? Definitely yes – there were hundreds of Breakout sessions for all AWS skill levels. AWS categorizes the Breakout session level as 100 (Introductory), 200 (Intermediate), 300 (Advanced), and 4 (Expert) depending on your experience working with AWS. You can also choose topics by learning track (e.g. Artificial Intelligence and Machine Learning, Containers, Serverless, etc. – there are too many to list - around 70 in total) or job role (e.g. Architect, Developer/Engineer, InfoSec, etc.). The Breakout sessions are great if you want a chance to ask questions or meet one-on-one with the presenter; however, these sessions are recorded and available on demand also on YouTube so the Workshops and Jam Sessions are a better use of your time. Workshops and Jam Sessions give you the opportunity to get your hands dirty and build something. AWS also planned many social events which provided an opportunity to either relax or interact with your peers. David and I even rode a mechanical bull (which earned us a nice AWS re:Invent 10th anniversary jacket). On the Expo floor, many vendors gave demos of AI/ML, ransomware defense, observability, cost management, and other services and tools that are designed to help you build, deploy, or manage, applications using AWS services. The AWS Builders' Fair is a fun and interactive way to learn how to apply AWS services to real-world use cases.

What other tips can I offer to someone who hasn’t been to AWS re:Invent? Register early if you want to attend in person (this year’s event sold out) and reserve seats in sessions that interest you most – they fill up quickly; although I found that I was always able to get into any session that had a waitlist. The conference is spread out among six hotels so be prepared to walk or look for the shuttles and manage your time so you can get to and from any scheduled session. The Casinos are large and like a maze so it’s easy to get lost. Meals are included in the conference fee so best bet is to remain inside a venue so as not to spend your lunch hour getting in and out of a building.

What’s next? As solutions and services provider with over 100 projects among our Health, Federal/Civilian, and National Security Sectors, PSI helps build, migrate, modernize, and/or secure many cloud applications for our customers. In order to refine our solutions, train employees, prepare for code challenges, and demonstrate concepts to our customers, we are deploying a DevSecOps Platform in AWS, Azure, GCP, and Oracle. Here we’ll apply our best practices, lessons learned, and innovation from our DoD, DHS, DOS, and VA projects in an environment that meets the well architected frameworks of the leading cloud providers and showcases the knowledge, experience, and agile development capabilities of our employees.

Thursday, September 2, 2021

Cost Management in the Cloud

Cloud environments differ from on-premise environments in many ways but one important aspect is the focus on operational expense (OPEX) versus capital expense (CAPEX). Many IT professionals are familiar with on-premise environments typically having lifecycle management policies for investment in hardware, software, and other infrastructure expenses. Network connectivity on-premise is usually a fixed/predictable cost and resource consumption is not a cost concern - hypervisor and storage equipment costs the same regardless of how much capacity is consumed. What is different in the cloud? The cloud pay-as-you go model requires a thinking differently about costs. Based on my experience with design, implementation, and management of projects in Amazon Web Services (AWS), these are some cost concerns to be aware of:

  • Cost Tools. In planning a new cloud deployment or migration, a cost estimate should be prepared using the AWS Pricing Calculator. The proposed design should meet the project's budget constraints and an alert created in AWS Budgets to ensure spending is in alignment with the budget. AWS Cost Explorer can be used to further analyze cost and usage of AWS resources.
  • Resource Sizing. In the cloud pay-as-you model, the size (CPU, memory, disk), performance (e.g. IOPS, network throughput), and number of virtual machines provisioned affect cost. In an on-premise data center, typically the virtualization platform, storage area network (SAN) or network attached storage (NAS) are paid up-front and sized to support the maximum workload, with some headroom for growth (almost always resulting in an over provisioning resources). Analyze workload requirements and size cloud resources appropriately. Use Auto Scaling Groups to automatically increase or decrease capacity based on demand, such as the number of connections, CPU, or memory utilization.
  • Shared versus Dedicated Hosts. When using Infrastructure as a Service (IaaS) in AWS, Elastic Compute Cloud (EC2) instances can be launched on shared infrastructure or Dedicated Hosts. Shared infrastructure is cheaper; however, be aware of compliance or licensing requirements which may require dedicated hosts. For example, the DoD Cloud Computing Security Requirements Guide requires dedicated hosts for Impact Level 5 workloads. Another reason for choosing dedicated hosting is software licenses bound to the number of sockets or physical cores of the host.
  • Commitment. In AWS, significant cost savings up to 72% can be realized by using Reserved Instances (RI) if you are able to commit to a 1 to 3 year term. Examine workloads - look for steady-state applications (e.g. authentication and authorization services, log collection and analysis, or any web application that is typically "always on") and make use of RIs. For ad-hoc or periodically-scheduled workloads such as batch processes, On-Demand or Spot instances can be used. If the workload can tolerate interruptions, Spot instances offer significant savings as compared to On-Demand instances. Spot instances are also a good choice for Auto Scaling Groups.
  • Egress and Cross Region Charges. AWS charges fees for data egress from their network to the Internet as well as across Regions within their network. There are also charges for Transit Gateway (TGW) and VPC Peering attachments and data transfer. On-premise network connectivity is typically a fixed monthly charge regardless of how much bandwidth is consumed. Variable data transfer charges which are unpredictable makes it difficult to factor in to the cost estimate; however, my experience has shown that egress charges amount to 1 to 3% of the overall cloud spending.
  • Tags. Tags attached to AWS resources are useful for configuration management, cost reporting, and cost efficiency. For example, by assigning a Tag with Key "Environment" and Value "Dev" to development resources, Amazon EventBridge and AWS Lambda can be used to turn those resources off after business hours thus realizing a cost savings up to 50% or more. By defining and activating a Tag for "Cost Center" as a User-Defined Cost Allocation Tag in the AWS Billing and Management console, costs can easily be tracked by customer, project, and/or team.
  • Abandoned Resources. Unused resources such as EC2 instances, Simple Storage Service (S3) buckets, Elastic Load Balancers (ELB), and databases in Amazon Relational Database Service (RDS) and DynamoDB can consume costs even though they are not in use. Use the cost tools mentioned above and audit monthly invoices to look for unused resources for which you are being charged.
  • Storage Tiering. AWS shared storage services such as S3 and Elastic File System (EFS) offer either automatic ("Intelligent Tiering") or user-defined lifecycle rules which migrate data to a cheaper storage class (e.g. "Infrequent Access") based on age (time since last accessed). Amazon FSx for Windows File Server and Amazon FSx for Lustre currently do not have the storage tiering feature.
  • Storage Lifecycle Management. Amazon Elastic Block Storage (EBS) Snaphots can be used to protect boot and data volumes attached to EC2 instances. In many environments I've found that because they are cheap, EBS snapshots are taken too frequently and retained indefinitely which overtime begins to increase cost. Analyze application requirements such as Recovery Point Objective (RPO) and retention policy and implement an EBS Snapshot management policy using  Amazon Data Lifecycle Manager. Amazon Data Lifecycle Manager can be used to control the frequency of EBS snapshots and automatically delete them once they reach a specified age thus meeting the RPO and retention requirements.
  • Serverless. AWS serverless offerings such as AWS Lambda, AWS Fargate, and Amazon API Gateway feature automatic scaling, built-in high availability, and a pay-for-use billing model to increase agility and optimize cost. By running a serverless application, we reduce costs by eliminating the need to provision EC2 instances and reduce operational expense by eliminating the need to patch, secure, backup, and monitor the underlying compute resources. We also reduce our cybersecurity exposure and labor expense in hardening operating system and web services (e.g. IIS, Apache, Nginx, etc.).. 
Resources:

Tuesday, July 20, 2021

Application and Code Testing

Application Security (AppSec) Strategy. "Shift-left" and get security testing incorporated early in the software development lifecycle (SDLC) - providing the security in DevSecOps. What problems need to be addressed with application security? Software Composition Analysis (SCA), securing Infrastructure as Code (IaC), security development infrastructure (e.g. source code repositories, container repositories, build systems), ensuring the confidentiality, integrity, and availability of the application in production. 

The following is a list of tool categories aimed at testing the security as well as stability or resiliency of an application and/or its code base. I have a few more draft notes written about this in OneNote, Sticky Notes, and the SharePoint blog I had started migrating to last year (abandoning that effort), so this post is by no means completed and will be continue to be expanded as I consolidated those notes.

Software Composition Analysis (SCA). Analysis of open-source component dependencies to identify vulnerabilities. Not a line-by-line scan of code as with SAST.
  • Contrast Security
  • Cycode
  • MergeBase
  • ShiftLeft
  • Snyk.
  • Veracode.
  • WhiteSource.
Pipeline Composition Analysis (PCA). Advances SCA to identify vulnerabilities in the software delivery pipeline.
  • Cycode
Software Bill of Materials. A software bill of materials is required per the White House Executive Order on Improving the Nation's Cybersecurity, May 12, 2021.Tools should be able to output a report in one of these three reporting formats:  Software Package Data Exchange (SPDX), CycloneDX, or Software Identification (SWID) Tags (see https://fossa.com/blog/software-bill-of-materials-formats-use-cases-tools/). The SPDX specification has been published as ISO/IEC 5962:2021 and recognized as the open standard for security, license compliance and other software supply chain artifacts.  

 Interactive Application Security Testing (IAST). 

Static Application Security Testing (SAST).
  • Checkmarx.
  • GitLab Ultimate 10.3. If  you are using GitLab CI/CD, you can analyze your source code for known vulnerabilities using SAST. Supported languages and frameworks include:  .NET, C/C++, Elixir (Phoenix), Go, Groovy, Java, JavaScript, Node.js, PHP, Python, Ruby on Rails, Scala, and Typescript. The output is a SAST report artifact that can be included in a GitLab Security Dashboard.
  • Micro Focus Fortify Static Code Analyzer.
  • Parasoft. https://blog.executivebiz.com/2021/10/parasofts-software-security-testing-tool-gets-ok-for-use-on-dod-devt-programs/. 
  • ShiftLeft
  • Synk. Integrates with 30 developer tools including six integrated development environments (IDE) (Jetbrains, Visual Studio, Eclipse, ...). Partner with Rapid 7 for DAST. Call Friday 7/21/2021.
  • WhiteSource. SAST solution announced 2/16/2022 based on technologies acquired from Xanitizer and DefenseCode. Able to identify over 70 types of security flaws including OWASP Top 10 and SANS Top 25.
Dynamic Application Security Testing (DAST).
  • Checkmarx.
  • GitLab Ultimate 10.4. If you are using GitLab CI/CD, you can analyze your running web application(s) for known vulnerabilities using DAST. DAST used the open source tool OWASP ZAProxy to perform an analysis of your running web application. DAST can be configured to do a passive or active scan (active scans will attempt to attack your application and thus provide a more extensive security report). The output is a DAST report artifact that can be included in a GitLab Security Dashboard.
  • Micro Focus Fortify WebInspect.

    Container Scanning

    • Anjuna.
    • Aqua Security.
    • Bridgecrew.
    • Grype. Anchore’s open source Grype vulnerability scanner tool for containers is generally available for DevOps teams that are running the latest version of the GitLab CI/CD platform. Grype leverages Syft libraries that employ deep inspection algorithms to create an accurate software bill of materials (SBOM) for an application and then runs a scan to identify vulnerabilities. That data is then surfaced within a GitLab workflow to advance adoption of DevSecOps best practices.
    • Kubscape. ARMO’s Kubescape tool, based on guidance from a 52-page joint report co-authored by the National Security Agency (NSA) and the Cybersecurity and Infrastructure Security Agency (CISA), can test whether Kubernetes clusters have been deployed securely. The Kubescape tool is based on open source software the company created to secure Kubernetes environments using the Open Policy Agent (OPA) framework being advanced under the auspices of the Cloud Native Computing Foundation (CNCF)
    • Lacework Labs.
    • NeuVector.
    • Rapid 7.
    • RapidFort.
    • Snyk. Build time.
    • sysdig.
    • Tenable.io CS Scanner.
    • Trivy.
    • Twistlock (now owned by Palo Alto). Run time.

    Infrastructure as Code (IaC). Analysis of deployment templates, e.g. JSON or YAML files used by AWS CloudFormation, Azure, GCP, Terraform, etc.)

    Observability

    • Metrics
      • Amazon CloudWatch. Amazon CloudWatch Events and EventBridge for alerting.
    • Events
    • Logs
      • Amazon CloudWatch. Amazon CloudWatch Events and EventBridge for alerting.
      • Splunk. Talal Balouch from SecuriGence is an expert.
    • Traces
      • Amazon X-Ray. Works with Amazon Elastic Compute Cloud (EC2), Amazon EC2 Container Service (Amazon ECS), AWS Lambda, AWS Elastic Beanstalk.
    • Analysis of logs, metrics, traces
    Chaos Engineering. An approach to application fault tolerance that intentionally provokes errors in live deployments. It incorporates an element of randomness to mimic the unpredictability of real-world outages.

    Failure Mode and Effects Analysis (FMEA). https://asq.org/quality-resources/fmea. 

    Vendors/Products:
    • Acunetix
    • Akeero
    • ARMO.
    • Azure Monitor
    • Aqua Security
    • Bridgecrew.
    • BluBracket.
    • Checkmarx
    • Chronosphere.io
    • Contrast Security
    • Cycode
    • Datadog.
    • Data Theorem
    • env0
    • Contrast Security
    • Fugue. Provide free masterclasses on cloud security.
    • GitHub
    • GitLab
    • HCL Software
    • Instana
    • Invincti
    • Jfrog
    • Lacework Labs
    • Lightstep.
    • Logz.io
    • MergeBase
    • Micro Focus
    • Moogsoft. 
    • Neuvector
    • New Relic.
    • NTT Application Security (acquired WhiteHat Security)
    • Onapsis
    • Parasoft.
    • Rapid 7.
    • RapidFort
    • ShiftLeft
    • SonarQube
    • Sonatype
    • Snyk.
    • StackState.
    • Synopsys Software Integrity Group
    • Sysdig
    • Veracode. Forrester Research recently released The Forrester Wave™: Software Composition Analysis, Q3 2021 report with Veracode ranked as a strong performer for software composition analysis (SCA). Evaluating 10 SCA vendors against 37 criteria, the report is helpful for security professionals who are selecting an SCA vendor to best suit their organization’s needs. 2021 Gartner Peer Insights Customers’ Choice for AST.
    • Traceable.AI. API security
    • Trilio. Data Protection for Kubernetes. See GigaOm Radar for Kubernetes Data Protection Report.
    • WhiteSource. 
    Other tools to lookup:  Datadog, PagerDuty, Gremlin

    Security criteria:  CIS Security Benchmarks, Cyber.mil STIGs, SRGs, UCF.

    Beyond the application:  DDoS protection, Web Application Firewall (WAF), packet analysis (e.g. Snort, VPC Flow Logs), Incident Response Plan (IRP), Business Continuity Plan (BCP), Disaster Recovery Plan (DRP), Privileged Account Management (PAM), Zero Trust Network Architecture (ZTNA), ...

    Tuesday, April 27, 2021

    Use of Personal Email for Government Business

    Each government entity most likely has their own policy(ies); however, the overarching one may be that using personal email for government business must be in compliance with the Federal Records Act (44 U.S.C Chapter 31). ​The National Archives and Records Administration (NARA) is charged with enforcing the Federal Records Act and Office of Management and Budget (OMB) requirements that include email and instant messages​. NARA issued Bulletin 2014-06, Guidance on Managing Email, September 15, 2014, addressed to heads of Federal agencies, states that email sent on personal email accounts pertaining to agency business and meeting the definition of Federal records (44 U.S.C. 3301) must be filed in an agency recordkeeping system.

    References:

    DoD CIO Web and Social Media Policies

    Thursday, February 27, 2020

    Security Reports

    Breaches
    Threats

    Wednesday, October 30, 2019

    Site Reliability Engineering (SRE)

    Resources:

    • SRE Weekly. SRE Weekly is a newsletter devoted to everything related to keeping a site or service available as consistently as possible.  SRE (Site/Service Reliability Engineering) isn’t just about automated failover or fault-tolerant architectures — although of course those are important.  It’s about a holistic view of reliability that takes into account everything from servers to human factors to processes to automation and more. Blog, RSS feed, and Twitter.
    • USENIX SREcon. SREcon is a gathering of engineers who care deeply about site reliability, systems engineering, and working with complex distributed systems at scale. Our purpose is to be inclusive as we bring together ideas representative of our diverse community, whether its members are focusing on a global scale, launching new products and ideas for a small business, or pivoting their approach to unite software and systems engineering. SREcon challenges both those new to the profession as well as those who have been involved in it for decades. The conference has a culture of critical thought, deep technical insights, continuous improvement, and innovation

    Tuesday, August 13, 2019

    PII and PHI in the DoD

    Personally Identifiable Information (PII) and Personal Health Information (PHI) is private information that can be used to distinguish or identify an individual. The PII the government collects must be relevant, accurate, timely, and complete (per Privacy Act of 1974). PII is normally stored in records that only individuals with need-to-know may access the records. PHI concerns records of an individual's physical or mental health. PHI includes any individually identifiable health information such as the medical history or medical billing information that was either created or received by a covered entity. Covered entities include health plans and almost all health care providers engaged in electronic billing and eligibility verification transactions. PHI is a subset of PII that requires additional safeguards. PHI is individually identifiable health information created or received by a covered entity, relating to the:  1) past, present, or future physical or mental health of an individual, 2) provision of health care to an individual, or 3) past, present, or future payment for provision of health care to an individual. Covered entities, whom are authorized to handle PHI, include health plans and health care providers. In the case of DoD, the TRICARE program is a covered entity health plan. Military Treatment Facilities are also healthcare provider covered entities. DoD 6025.18-R, DoD Health Information Privacy Regulation, contains detailed information on DoD Components that are and are not considered covered entities and obligations of non-covered entity DoD Components when they act as business associates of DoD covered entity components. When PHI is shared with a non-covered entity, it is no longer PHI and it is converted to PII. DoDI 8580.02, Security of Individually Identifiable Health Information in DoD Health Care Programs, defines exceptions and situations that are not considered covered entities.
    http://www.dtic.mil/whs/directives/corres/pdf/540011r.pdf
    DoD 5400.11-R, May 14, 2007
    DL1. DEFINITIONS
    DL1.14. Personal Information. Information about an individual that identifies, links, relates, or is unique to, or describes him or her, e.g., a social security number; age; military rank; civilian grade; marital status; race; salary; home/office phone numbers; other demographic, biometric, personnel, medical, and financial information, etc. Such information is also known as personally identifiable information (i.e., information which can be used to distinguish or trace an individual’s identity, such as their name, social security number, date and place of birth, mother’s maiden name, biometric records, including any other personal information which is linked or linkable to a specified individual).
    http://www.dtic.mil/whs/directives/corres/pdf/540011p.pdf
    DoDD 5400.11, May 8, 2007
    E2. ENCLOSURE 2
    E2.2. Personal Information. Information about an individual that identifies, links, relates, or is unique to, or describes him or her (e.g., a social security number; age; military rank; civilian grade; marital status; race; salary; home or office phone numbers; other demographic, biometric, personnel, medical, and financial information, etc). Such information also is known as personally identifiable information (e.g., information which can be used to distinguish or trace an individual’s identity, such as his or her name; social security number; date and place of birth; mother’s maiden name; and biometric records, including any other personal information which is linked or linkable to a specified individual.
    Regulations which apply to the administrative, physical, and technological controls pertaining to PII include:  Privacy Act of 1974, Freedom of Information Act (FOIA), Health Insurance Portability and Accountability Act (HIPAA) Privacy and Security Rules (45 CFR Parts 160 and 164), and Health Insurance Technology for Economic and Clinical Health (HITECH).  The Privacy Act of 1974 requires establishment of rules of conduct and safeguards for PII and requires the US Government to maintain accurate, relevant, timely and complete information. The FOIA keeps the public informed while protecting government interests and protects access to records exempt under the Privacy Act. The HIPAA Privacy and Security Rules 1) establish national standards for PHI use and disclosure and individual rights and 2) establishes national standards for administrative, physical, and technical PHI safeguards. HIGHTECH establishes breach notification standards for PHI, expands HIPAA security requirements to business associates of covered entities, and expands penalties for HIPAA violations.

    Risks associated with the misuse or improper disclosure of PII include:
    • Legal liability of the organization
    • Theft of the identity of the subject of the PII
    • Expense to the organization
    • Damage to the subject of the PII's reputation
    • Inconvenience to the subject of the PII
    • Loss of trust in the organization
    Administrative, physical, and technical safeguards at the organizational level include:
    Administrative safeguards include:
    • Restricting access to PII to people with need-to-know.
    • Reduce the volume and use of SSNs. Find alternative identification methods such as a CAC EDIPI.
    • Train individuals (orientation, specialized, management, training on systems of records containing PII). Ensure individuals can determine authorized access and need-to-know and limit access accordingly. Make sure use of PII matches the SORN.
    • Establish and follow policies and procedures for handling PII, specifically - defining the impact to affected individuals, actions, assigned agency roles and responsibilities, and consequences associated with losing or misusing PII.
    • Conduct risk assessments (Privacy Impact Assessment, or PIA) before collecting any PII to assess the level of risk to the individual or organization in collecting or maintaining PII. A PIA is conducted before an organization processes PII to ensure it meets legal, regulatory, and policy requirements and determines the risks of collecting, using, maintaining, and disseminating PII on electronic information systems. A PIA is required when an organization collects PII from:  an existing information system or electronic collection for which no PIA was previously completed or new information systems or electronic collections 1) before development or purchase, and 2) when converting paper records to electronic systems. A PIA is not required when the information system or electronic collection:  does not collect, maintain, or disseminate PII, is a National Security System (NSS), including one that processes classified information, or is solely paper-based.
    • Review and report on PII holdings (System of Records Notice, or SORN) annually in the Federal Register and report status to Congress. SORNs include a list of PII collected, system safeguards, purpose of collection, and access/correction processes.
    • Individuals should:  monitor and minimize the use of SSNs, determine authorized access adn need-to-know, determine if PII is necessary, ensure PII matches what is published in the SORN, be aware of the surrounding environment when engaging in a conversation involving PII, determine and ensure PII is correct (obtain directly from the subject, verify information is accurate, relevant, timely, and necessary, ensure any other information comes from an authorized, accurate source such as Government sources).
    Physical safeguards include:
    • Properly storing records in accordance with agency policy and procedures.
    • Employ access controls.
    • Secure hardware by locking in a secure room.
    • Establish policies and procedures for handling, transmitting, and disposing of paper and electronics (must comply with National Archives and Records Administration, or NARA, for records management requires for retention and disposal).
    • Test safeguards to ensure they are operating as intended.
    • Mark as CUI.
    • When transporting or transmitting PII, use cover sheet, the appropriate postal class, and wrapping.
    • Protect PII during working and non-working hours.
    • Follow NARA's Record Management guidelines for record retention and disposal (render destroyed PII unrecognizable and beyond reconstruction via shredding or incineration).
    • Test safeguards.
    Technical controls include:
    • Encrypting records in accordance with agency policies and procedures.
    • Provide secure systems for storing and transmitting electronic records which include:  encryption, remote access controls, time-out functionality, and logging and verifying access.
    • Ensure implementation of role-based access controls for the workforce.
    • Ensure workforce members understand their responsibilities for safeguarding electronic records.
    • Use only government-approved devices and software.
    • Use appropriate encryption.
    • Use access controls to limit access on shared drives to individuals with need-to-know.
    • Following agency policies and procedures for transmission of PII (i.e. confirming email or fax receipt, encrypting email, verification of need-to-know on mailing lists).
    • Follow rules for telework:  use of appropriate/approved systems to process PII, obtain approval from manager before extracting PII to another computer, never transmit PII via personal email.
    Administrative, physical, and technical safeguards at the individual level include:

    Administrative safeguards include at the individual level:
    • Monitor and minimize the use of SSNs. Use DoD ID numbers wherever possible for internal DoD business processes.
    • Determine authorized access and need-to-know (e.g. verify user credentials/authority) and limit access accordingly.
    • Ask yourself:
      • Is using PII necessary? Consider whether a task can be completed without PII. If the task cannot be completed without PII; if it cannot be completed without using or disclosing PII do not use or disclose more PII than is the minimum amount necessary to support the use or disclosure.
      • Make sure the use of PII matches the purpose of collection in the SORN. Do not use information that was previously collected in a system of records for a new use before altering the existing SORN or creating a new one and publishing it in the Federal Register. Do not even use a subset of existing PII for a new purpose, and do not maintain data collections in secret.
      • Is it safe to talk about this PII? Be aware of the surrounding environment when engaging in conversation involving PII. Ensure that telephone conversations are private. 
      • Do you have the right information, and is it correct? If possible, collect information directly from the subject of the PII; this will guarantee you have the most up-to-date information. Verify the data is accurate, relevant, timely, and necessary. Ensure that other information comes from the authorized official source, such as government sources. 
    Physical safeguards at the individual level include:
    • Mark PII as CUI.
    • Use cover sheets, postal class, or wrapping when transporting.
    • Reduce the risk of access to PII during business hours by covering or placing it out of sight when not directly working on it. Lock your computer when leaving it unintended. Store PII appropriately after working hours (e.g. locked or unlocked containers, desks, or cabinets. Dispose of all paper or electronic records according to the standards defined in the SORN or by NARA. You must render discarded PII unrecognizable and beyond reconstruction. 
    Technical safeguards at the individual level include:
    • Use government-approved devices and software. This safeguards PII because the government has determined these devices and software provide adequate protection. 
    • Make sure you are encrypting PII appropriately.
    • Use access controls to limit access to PII on shared drives to individuals.
    • Follow agency policies and procedures for transmitting PII, such as confirming fax receipt, encrypting emails, verifying email distribution lists contain only authorized individuals.
    • Follow rules for telework including using only a government-furnished computer, getting approval from a manager before extracting PII onto that computer, and must never transmit PII via personal email. 
    A Privacy Impact Assessment (PIA) is a risk assessment that must be completed before an organization begins gathering PII. A PIA analyzes how an organization handles information to ensure it satisfies requirements and determines the risks of collecting, using, maintaining, and disseminating PII on electronic information systems. DoD Form 2930, Privacy Impact Assessment, June 2017 is used. A PIA is required when an organization collects PIA from:
    • Existing information systems and electronic collections for which no PIA was previously completed.
    • New information systems or electronic collections:
      • Before development or purchase
      • When converting paper records to electronic systems.
    A PAI is not required when the information system or electronic collection:
    • Does not collect, maintain, or disseminate PII.
    • Is a National Security System, including ones that process classified information.
    • Is solely paper-based.
    A PIA:
    • Analyzes how organization handles information to ensure it satisfies legal, regulatory, and policy requirements.
    • Determines the risks of collecting, using, maintaining, and disseminating PII on electronic information systems.
    • Aims to mitigate unauthorized use or disclosure risks.
    If an organization determines that it must collect and maintain PII that will be retrieved by a personal identifier within that systems, a System of Records Notice (SORN) must be published in the Federal Register. A System of Records is a group of records under an organization or agency's control from which personal information about an individual retrieved using the individual's name or some other unique identifier. A SORN notifies the public that an agency will collect and retrieve PII in a system of records. It must be published before PII is collected. SORNs include: the legal authority to collect the PII, the type of PII that will be collected, the safeguards in place to protect the PII, how individuals can determine if they are part of that system, and how they can obtain a copy of their record if they are a part of that system.

    All of the safeguards and best practices that apply to PII also apply to PHI but PHI receives greater protection. The HIPAA Privacy and Security Rules require covered entities to have in place appropriate administrative (e.g. access restrictions), technical (e.g. encryption), and physical (e.g. proper physical records storage) safeguards to protect PHI. Based on its risk analysis and risk management plan, each covered entity can establish its own specific administrative, physical, and technical safeguards. They do this by evaluating their needs, the types of PHI involved, and specific business risks. For DoD covered entity Components, individual implementation is subject to DoD's implementation of the HIPAA Privacy and Security Rules. Covered entities must train workforce members on the policies and procedures that apply to PHI. Other than required disclosures of an individual's PHI to that individual or use and disclosure of PHI for treatment of an individual, covered entities must limit permitted uses and disclosures of PHI to the minimum necessary to accomplish the purpose of that use of disclosure. Non-covered entities that are business associates of covered entities also have responsibilities to safeguard PHI. They must make sure their workforce members are able to recognize PHI and understand that HIPAA Privacy and Security Rules provide additional protection and controls for PHI beyond what is required for PII.
    DoD 6025.18-R, "DoD Health Information Privacy Regulation." JAN 2003, implements the HIPAA Privacy Rule within DoD and its Components and defines permitted uses and disclosures of PHI. DoD 8580.02-R, "DoD Health Information Security Regulation," 12 JUL 2007 implements the HIPAA Security Rule within DoD and its Components and defines administrative, physical, and technical safeguards for electronic PHI.

    DoD 8580.02-R, DoD Health Information Security Regulation, contains requirements for electronic PHI risk analyses and requires organizations to:
    • Assess potential risks and vulnerabilities to confidentiality, integrity, and availability of all electronic PHI they create, receive, store, or transmit.
    • Conduct a risk analysis that includes:  threat assessment, exploitable vulnerabilities, and residual risk determination.
    • Consider both organizational and technical assessments that address all security areas.
    • Consider all losses to be expected if security measures were not in place, including losses caused by unauthorized use and disclosure, as well as losses of data integrity or accuracy.
    Authorized use and disclosure of PII: 
    The Privacy Act limits the rights of an agency to disclose PII to any person or other agency . The Disclosure Rule:  No disclosure of a record in a system of records unless:
    • the request is made in a written request for whom the record pertains or that individual has given prior consent.
    • disclosure is made under one of the Privacy Act's 12 permitted disclosures, including routine use as defined in the SORN. Routine use is the purpose for which the government collected it (as defined in the SORN).
    The 12 exceptions to the Privacy Act that permit disclosure of PII to another person or agency:
    1. To officers and employees of the agency maintaining the record who have a need for the PII in their performance of duties
    2. When the FOIA requires release
    3. For a "routine use" identified in the SORN that has been published in the Federal Register. The Privacy Act defines "routine use" as disclosure of a record for the purpose compatible with the purpose for which the government collected it. The SORN identifies routine uses and disclosures of the system's records.
    4. To the Census Bureau for the purposes of conducting a census or survey
    5. For statistical research or reporting without individually identifying data
    6. to the National Archives and Records Administration (NARA)
    7. To a law enforcement agency for a civil or criminal investigation
    8. When there are compelling or emergency circumstances affecting someone's health or safety
    9. To Congress, including its committees or subcommittees
    10. To the Government Accountability Office and Comptroller General
    11. Pursuant to a court order
    12. To a consumer reporting agency
    A breach occurs when an individual or organization improperly uses or discloses PII. PII is lost, stolen, compromised or used outside of parties with need-to-now or as part of routine use. OMB M-17-12 requires agencies to establish a breach notification policy and plan. If a breach occurs, the head of the organization must notify the proper individuals and provide this information:
    • What happened, the date of the breach, and how it was discovered.
    • Types of personal information involved.
    • Whether the information was encrypted or otherwise protected.
    • Steps taken to protect the affected individuals from harm.
    • Agency investigation and remediation actions.
    • Point of contact for affected individuals.
    Within the DoD, per DoD 5400.11-R, the organization must report the discovery of a breach within:
    • one hour to US-CERT
    • 24 hours to Component Privacy Office
    • 48 hours to the Defense Privacy and Civil Liberties, and Transparency Division
    After discovering a potential breach of PII, an individual should:
    • immediately notify the appropriate authority:  Supervisor, Privacy Officer, or System Manager. In some cases, your manager may have to notify DoD and national authorities, as well as those individuals whose personal data was compromised. 
    • Document when and where the potential breach was found:  record the URL for PII on the Internet.
    • If the breach includes PHI, a simultaneous, independent report is required.
    Authorized use and disclosure of PHI. A covered entity may use or disclose PHI:
    A covered entity may use of disclose PHI:
    • To the subject of the PHI
    • Pursuant to the PHI subject's written authorization
    • For treatment, payment, or health care operations
    • As otherwise permitted or required by the HIPAA Privacy Rule
    A breach of PHI is defined as the acquisition, access, use, disclosure of PHI in a manner not permitted under the HIPAA Privacy Rule that compromises the security or privacy of PHI.
    For a breach of PHI affecting fewer than 500 individuals, covered entities must:
    • Notify individuals whose PHI may have been breached within 60 days of the incident.
    • Report all such breaches to the Secretary of the Health and Human Services (HHS) annually.
    For PHI breaches affecting 500 or more individuals, covered entities must, within 60 days of the incident:
    • Notify individuals whose PHI may have been breached.
    • Notify the Secretary of HHS.
    • Notify prominent media outlets serving the State or jurisdiction where affected individuals reside, usually by issuing a press release.
    In the event of a breach of PHI, individuals working at a covered entity must:
    • Report lost, stolen, or compromised PHI to the organization's designated official which describes the information compromised and when and where the discovery occurred.
    If organizations and individuals do not comply with the laws for safeguarding PII and PHI, they are are subject to civil penalties for not protecting PII and PHI. Individuals are subject to criminal penalties for PII and potentially civil penalties for PHI. 
    Organizations can incur civil penalties for:
    • unlawfully refusing to remove a record.
    • unlawfully refusing access to a record.
    • Failing to maintain accurate, relevant, timely, and complete information.
    • Failing to comply with any Privacy Act provision or agency rule that adversely affects the subject of the record.
    • Failing to comply with the HIPAA Privacy and Security Rules.
    Penalties for failing to protect PII include damages and reasonable attorney fees. Penalties for failing to protect PHI include fines dependent on the nature and extent of harm caused.
    Criminal penalties can be incurred by any official or employee who:
    • Knowingly discloses PII from a system of records to an unauthorized person.
    • Failing to publish SORN in Federal Register for a system of records.
    Criminal penalties for individuals failing to comply with regulations to protect PII include:  misdemeanor conviction and fine up to $5,000. Individuals who knowingly or wrongfully obtain or disclose PHI are subject to the following criminal penalties:  Up to one year in prison and fine up to $50,000. For offenses committed under false pretenses or for commercial purposes (such as selling PHI or using PHI for personal gain or malicious harm), criminal penalties:  up to 10 years in prison and fines up to $250,000.
    Individuals can incur civil penalties for failing to comply with the requirements and standards of the HIPAA rules. The HITECH Act increased the fines in 2009. Four tiers of penalties are defined for failure to protect PHI, depending on the severity:  Tier A, Tier B, Tier C, and Tier D:
    • Tier A. Violations in which the offender did not realize he or she violated the act (and by exercising reasonable diligence would not have known):  $100 to $50,000 for each occurrence.
    • Tier B. Violations due to reasonable cause and not to willful neglect:  $1,000 to $5000 for each occurrence.
    • Tier C. Violations due to willful neglect that the organization did not correct within 30 days of when the violation was discovered (or should have been discovered):  $10,000 to $50,000 per violation.
    • Tier D. Violations due to willful neglect that the organization did not correct:  $50,000 to $1.5M for identical violations occurring within a calendar year.
    Consequences of PII Loss to Individuals:
    • Identity theft
    • Fraud (e.g. credit card)
    • Other criminal acts
    • Damage reputation
    • Embarrassment
    • Inconvenience
    Consequences of PII Loss to Organizations
    • Loss of trust
    • Legal liability
    • Remediation costs (e.g. providing credit monitoring services to individuals affected by the lost or misused PII). DoD cost due to OMB breach in 2015 was $132M.
    Examples of PII:
    • Social Security Number (SSN)
    • Driver's License Number
    • Fingerprint
    REFERENCES:
    • Identifying and Safeguarding PII Course
    • DoD 6025.18-R​, "DoD Health Information Privacy Regulation," JAN 2003. Implements the HIPAA Privacy Rule within the DoD and its Components. Sets out permitted uses and disclosures of PHI.
    • DoDI 8580.02, "Security of Individually Identifiable Health Information in DoD Health Care Programs," August 12, 2015. Implements the HIPAA Security Rule within DoD and its Components. Defines administrative, physical, and technical safeguards for electronic PHI.
    • DoD 8580.02-R, "DoD Health Information Security Regulation," 12 JUL 2007.
    • DoD 5400.11-R, "Department of Defense Privacy Program," 14 MAY 2007. Regulation governing DoD Privacy Program.
    • DoDD 5400.11, "DoD Privacy and Civil Liberties Program," 29 January 2019, Change 1 December 8, 2020. Defines DoD Privacy Program.
    • ​http://www.doncio.navy.mil/contentView.aspx?id=2428
    • Army Course:  WNSF - Personally Identifiable Information (PII) v2.0
    • E-Government Act of 2002. Improves interaction and communication between public and private sectors. Amended by FISMA.
    • Federal Information Security Modernization Act (FISMA) of 2014. Identifies Federal information security controls.
    • OMB Guidance for Implementing the Privacy Provisions of the E-Government Act of 2002. Guides implementation for protecting information.
    • OMB Memorandum M-17-12, Preparing for and Responding to a Breach of Personally Identifiable Information. Identifies Federal information security controls. 
    • OMB Memorandum 07-16, Safeguarding Against and Responding to the Breach of Personally Identifiable Information (check if this has been superseded by M-17-12)
    • ISO 29134 (Guidelines for Privacy Impact Assessment, June 2017)