The world of information security, auditing, and regulatory compliance can be a complicated place. We put together this glossary of common terms and phrases you need to know so you can stay informed and be prepared for your next compliance audit.
According to the Office for Civil Rights, the Security Rule defines administrative safeguards as, “administrative actions, and policies and procedures, to manage the selection, development, implementation, and maintenance of security measures to protect electronic protected health information (ePHI) and to manage the conduct of the covered entity’s workforce in the relation to the protection of that information.”
Examples of administrative controls can be things like employee training, security awareness, written policies and procedures, incident response plans, business associate agreements, and background checks.
Whether you use a SOAP or REST API, a poorly secured API can open security gaps for anything that it is associated with. API penetration testing looks for vulnerabilities in the endpoints of your API, as well as configuration issues that could be exploited. In fact, some of the most common vulnerabilities are improper authentication and authorization issues within the API.
PCI DSS defines cardholder data as: “At a minimum, cardholder data consists of the full PAN. Cardholder data may also appear in the form of the full PAN plus any of the following: cardholder name, expiration date and/or service code.” In short, as the name implies, cardholder data is any data stored related to a user’s card number or payment information.
In June 2018, California Governor Jerry Brown signed into law AB 375, enacting The California Consumer Privacy Act of 2018 (CCPA) which went into effect on January 1, 2020. The purpose of CCPA is to give consumers more rights related to their personal data, while also requiring businesses to be more transparent about the way personal data is used and shared. Because of California’s reputation as a hub for technology development, this law speaks to the needs of its consumers which continue to evolve with technological advancements and the resulting privacy implications surrounding the collection, use, and protection of personal information.
Let’s face it: no one can write 100% bug-free code all the time. Code review takes a hybrid approach that includes both automation and manual assessment to uncover flaws in your code and potential vulnerabilities. A code review looks for logic issues, security issues, and anything that would be exploitable if discovered and abused, and can also look at general code best practices for ongoing safety and security.
A standard penetration test is only a snapshot of what the security posture of your application or network had at the time of testing. Continuous penetration testing is a nonstop, ongoing pen testing process that more naturally simulates how an attacker will try to breach your defenses.
The natural or legal entity that regulates the purpose and means of processing personal data. The greater the decision-making authority an organization has regarding what personal data to obtain from data subjects and how to use that personal data, the more likely it is that an organization takes on the responsibilities of a data controller.
HIPAA refers to laws that apply to covered entities and business associates regarding the privacy, security, and accessibility of electronic protected health information (ePHI). Covered entities and business associates use this information to provide services to the public such as medical care, and the filing and billing of medical claims. Covered entities include doctor’s offices, hospitals, healthcare providers, health plans, and healthcare clearing houses.
Article 28(3)Â of GDPR requires that controllers, processors, and sub-processors must enter into written contracts, or data processing agreements, in order to share personal data. DPAs create liability limitations and establish roles and responsibilities for controllers, processors, and sub-processors.
Because GDPR uses informal descriptions for the term “data subject,” the public has been left with varying interpretations and significant challenges. We generally see five definitions proposed for data subjects: a person located in the EU, a resident of the EU, a citizen of the EU, an EU resident/citizen physically located anywhere in the world, or a person whose personal data is processed within the EU, regardless of that person’s location. Organizations should closely monitor regulatory and legal developments related to the definition of “data subject.”
A Denial of Service (DoS) attack is a type of an external intrusion used by malicious hackers to shut down the web servers of organizations – banking, commerce, government, and trade companies – by flooding or crashing them and exploiting vulnerabilities in their systems. Similarly, a Distributed Denial of Service (DDoS) attack is a more extreme, complex form of DoS because hackers infiltrate a system from more than one location, increasing the volume of machines flooding a system and making it more difficult to track and shut down.
GDPR is the European Union’s General Data Protection Regulation (GDPR). The law gives data subjects rights over their personal data and establishes obligations for any organization around the world that is processing the data of an EU data subject, making the applicability of the law follow data rather than following a data subject or physical location.
GDPR requires all data controllers and data processors that handle personal data of data subjects to apply appropriate security and organizational measures in order to safeguard the confidentiality, integrity, and availability of processing services. GDPR was enacted in 2016 and became enforceable on May 25, 2018.
The Health Insurance Portability and Accountability Act (HIPAA) sets a national standard for the protection of consumers’ PHI by mandating risk management best practices and physical, administrative, and technical safeguards. HIPAA was established to provide greater transparency for individuals whose information may be at risk, and the Department of Health and Human Services’ Office for Civil Rights (OCR) enforces compliance with the HIPAA Privacy, Security, and Breach Notification Rules.
One of the seven major data processing principles of GDPR is to ensure that personal data is processed lawfully, fairly, and transparently. To comply this principle, Chapter 6 of the GDPR requires any organization processing personal data to have a valid legal basis for that personal data processing activity. Think of these as scenarios in which it would be lawful to process data. GDPR provides six legal bases for processing: consent, performance of a contract, legitimate interest, vital interest, legal requirement, and public interest.
There are 4 levels of PCI compliance, based on number of transactions processed within a year. The levels are as follows:
Network penetration testing tests the strength of your network from the inside out. This is accomplished in one of two methods:
A third-party payment processor is a depository customer of a bank that uses their banking relationship to process payments on behalf of other companies through its bank. They are typically referred to as processors that process ACH and/or remotely created checks (RCC), although it is typically much broader than that because banks do not have a contractual relationship with the TPPP’s merchant clients, so you can have credit cards, checks that are not remotely created, and return products that fall under this umbrella term. It is also important to note that TPPP is also synonymous with TSP, or third-party senders, by NACHA if they are processing ACH payments and must adhere to the third-party vendor requirements under the rules.
The Payment Card Industry Data Security Standard (PCI-DSS), which consists of nearly 400 individual controls and is a critical part of staying in business for any merchant, service provider, or subservice provider who is involved in handling cardholder data. In fact, if you are a merchant, service provider, or subservice provider who stores, processes, or transmits cardholder data, you are required to comply with the PCI DSS.
Personal data is any identifiable information related to a data subject. For example: name, geographic location data, email address, IP address, photographs, video or voice recordings, biometric data, or an online identifier of the specific physical, physiological, genetic, mental, economic, cultural, or social identity of a data subject.
Phishing is any effort from an attacker to gain sensitive information from an individual via email, social media, and even phone calls. In the context of a business entity, these malicious individuals make contact with employees asking for private information that can lead to access of company systems, processes, or data. These attacks are not personalized. Instead, they are mass-generated with the hope at least one individual will fall for the trap.
According to the Security Rule, physical safeguards are, “physical measures, policies, and procedures to protect a covered entity’s electronic information systems and related buildings and equipment, from natural and environmental hazards, and unauthorized intrusion.” Each organization’s physical safeguards may be different, and should be derived based on the results of the HIPAA risk analysis.
PAN stands for Primary Account Number, and it is the most critical piece of cardholder data when it comes to PCI compliance. Since the PAN can be used in conjunction with other pieces of cardholder data, there are extra steps and regulatory compliance that must be met in order to ensure user data is properly secured.
The PCI DSS says, “The primary account number (PAN) is the defining factor for cardholder data. If cardholder name, service code, and/or expiration date are stored, processed or transmitted with the PAN, or are otherwise present in the cardholder data environment (CDE), they must be protected in accordance with applicable PCI DSS requirements.”
One of the 5 Trust Services Criteria of SOC 2 audits. Including the Privacy Principle in your SOC 2 audit report ensures that your organization is handling client data in accordance with any commitments in the privacy notice as committed or agreed upon. The Privacy Principle also demonstrates that you’re handling client data in accordance with criteria issued by the AICPA, including management, notice, choice and consent, collection, use retention and disposal, access, disclosure to third parties, security, quality, and monitoring and enforcement.
The Privacy Rule is a national standard intended to protect patients’ protected health information (PHI). The HIPAA Privacy Rule requires healthcare organizations and their third parties to implement appropriate safeguards to protect the privacy of this information. It regulates things like appropriate use and disclosure of PHI, patient access to PHI, and patient rights.
Processing is any action that happens to or uses personal data, including accessing, collection, storage, archiving, reviewing, or destroying.
A processor is the natural or legal entity that processes personal data in support of a controller. Processors cannot process data without the authority of the data controller; therefore, processors must provide controllers with sufficient GDPR compliance guarantees, notification of data breaches and adding/changing of sub-processors.
A SOC 1 engagement is an audit of the internal controls which a service organization has implemented to protect client data, specifically internal controls over financial reporting. SOC 1 is the standard used by CPAs during a SOC 1 engagement to evaluate, test, and report on the effectiveness of the service organization’s internal controls.
Understanding the difference between a SOC 1 Type I and SOC 1 Type II is simple; it comes down to the audit period. While both a SOC 1 Type I and SOC 1 Type II report on the controls and processes at a service organization that may impact their user entities’ internal control over financial reporting, the main difference between the two types of audits is the period in which the auditor verifies the effectiveness of internal controls. SOC 1 Type I audits will assess controls and processes that could impact entities’ ICFR for a specific point in time. On the other hand, a SOC 1 Type II audit will assess controls and processes that could impact entities’ ICFR over a period of time.
A SOC 2 audit evaluates controls that directly relate to the AICPA’s Trust Services Criteria. This means that a SOC 2 audit report focuses on a service organization’s internal controls as they relate to security, availability, processing integrity, confidentiality, and privacy of a system.
A SOC 2 Type I and SOC 2 Type II both report on the non-financial reporting controls and processes at a service organization as they relate to the Trust Services Criteria. There are many other similarities between SOC 2 Type I and SOC 2 Type II reports, but the key difference is that a SOC 2 Type I report is an attestation of controls at a service organization at a specific point in time, whereas a SOC 2 Type II report is an attestation of controls at a service organization over a minimum six-month period.
A SOC for Cybersecurity examination is how a CPA reports on an organization’s cybersecurity risk management program. Its intent is to communicate information regarding an organization’s cybersecurity risk management efforts, which can give boards of directors, analysts, investors, business partners, industry regulators, and users an entity-wide perspective and confidence in an organization’s cybersecurity risk management program.
A SOC for Cybersecurity examination reports on three elements: Management’s Description, Management’s Assertion, and Practitioner’s Opinion.
Social engineering leverages and manipulates human interactions to compromise your organization. This could be something like bypassing a procedure and letting a guest into an employee-only area or believing someone’s unusual circumstances that lead to breaking policy. Eventually, these breaks in policy or procedure lead to malware or unauthorized access to your system.
The SSAE 16 (Statement on Standards for Attestation Engagements no. 16), born in 2011, provides auditors a way to report on things other than financial reports. Instead, SSAE 16 reports on the design and operating effectiveness of controls at a service organization as they relate to their clients’ ICFR. Prior to the SSAE 16, CPAs used what was known as SAS 70.
In 2016, the AICPA updated the Statement on Standards for Attestation Engagements No. 16 (SSAE 16) to No. 18 (SSAE 18). This change was made to simplify and converge attestation standards related to SOC 1 audits. SSAE 18 has also expanded to cover more types of attestation reports (including SOC 2), whereas SSAE 16 was limited to only SOC 1 reports.
Independent, public authorities for each EU member state that are responsible for monitoring the application of GDPR and addressing non-compliance. For example: National Commission of Computing and Freedoms in France, the Federal Commissioner for Data Protection and Freedom of Information in Germany, the Agency of Protection of Data in Spain, and the Information Commissioner’s Office in the United Kingdom.
According to the HIPAA Security Rule, technical safeguards are “the technology and the policy and procedures for its use that protect electronic protected health information and control access to it.” So while administrative safeguards involve people and access and physical safeguards involve the physical premises, technical safeguards look at the technology and platforms used to protect sensitive PHI.
The assessment and verification of an organization’s systems and controls by an independent, third-party agency.
A threat is a potential event that could take advantage of your protected asset’s flaws and result in the loss of your security’s confidentiality, integrity, and/or availability (C-I-A). Threats result in non-desirable performance of critical assets. There’s always a potential flaw that could be exposed, and when a threat is identified, think about the way it could affect the pillars of security: integrity, availability, and confidentiality.
Wireless penetration testing begins with a vulnerability assessment, where penetration testers utilize multiple tools to gain initial knowledge specific to wireless networks and applications. A vulnerability assessment is not a replacement for a penetration test, though. After interpreting those results, penetration testers will use manual techniques and human intuition to attack those vulnerabilities.
