sp-030-api-inbound This model holds one security pattern, sp-030-api-inbound, taken out of the Cyber Security Coalition pattern library. It carries the two views of the pattern, every element on them, the relationships between those elements, and the STRIDE-LM categories the threats are anchored to. Nothing else from the library is included. The threat model shows why each control is in the pattern. The control realisation shows which security service delivers it. Licence: Creative Commons Attribution-ShareAlike 4.0 International, CC BY-SA 4.0. https://creativecommons.org/licenses/by-sa/4.0/ Contributed by the Cyber Security Coalition, Enterprise Security Architecture focus group. https://cybersecuritycoalition.be/focus-group/esa-enterprise-security-architecture/ Control identifiers and control text are NIST SP 800-53 Rev 5. Threat names that begin with CAPEC are MITRE CAPEC meta attack patterns. Threat categories that begin with STRIDE are STRIDE-LM. The "contains" property says what each of the three is. Generated from model.archimate. Regenerate it after any change to the model; do not edit it by hand. https://github.com/CSC-ESA/Patterns https://csc-esa.github.io/Patterns Creative Commons Attribution-ShareAlike 4.0 International, CC BY-SA 4.0. https://creativecommons.org/licenses/by-sa/4.0/ Contributed by the Cyber Security Coalition, Enterprise Security Architecture focus group. https://cybersecuritycoalition.be/focus-group/esa-enterprise-security-architecture/ NIST SP 800-53 Rev 5 control identifiers and text, a US government publication in the public domain. MITRE CAPEC threat names and descriptions, free to use with attribution to MITRE. STRIDE-LM threat categories. model.archimate AC-10: Concurrent Session Control Limit the number of concurrent sessions for each [Assignment: organization-defined account and/or account type] to [Assignment: organization-defined number]. AC-10 Organizations may define the maximum number of concurrent sessions for system accounts globally, by account type, by account, or any combination thereof. For example, organizations may limit the number of concurrent sessions for system administrators or other individuals working in particularly sensitive domains or mission-critical applications. Concurrent session control addresses concurrent sessions for system accounts. It does not, however, address concurrent sessions by single users via multiple system accounts. SC-23. AC-12: Session Termination Automatically terminate a user session after [Assignment: organization-defined conditions or trigger events requiring session disconnect]. AC-12 Session termination addresses the termination of user-initiated logical sessions (in contrast to SC-10, which addresses the termination of network connections associated with communications sessions (i.e., network disconnect)). A logical session (for local, network, and remote access) is initiated whenever a user (or process acting on behalf of a user) accesses an organizational system. Such user sessions can be terminated without terminating network sessions. Session termination ends all processes associated with a user’s logical session except for those processes that are specifically created by the user (i.e., session owner) to continue after the session is terminated. Conditions or trigger events that require automatic termination of the session include organization-defined periods of user inactivity, targeted responses to certain types of incidents, or time-of-day restrictions on system use. MA-4, SC-10, SC-23. AC-20: Use of External Systems a. [Selection (one or more): Establish [Assignment: organization-defined terms and conditions]; Identify [Assignment: organization-defined controls asserted to be implemented on external systems]], consistent with the trust relationships established with other organizations owning, operating, and/or maintaining external systems, allowing authorized individuals to: 1. Access the system from external systems; and 2. Process, store, or transmit organization-controlled information using external systems; or b. Prohibit the use of [Assignment: organizationally-defined types of external systems]. AC-20 External systems are systems that are used by but not part of organizational systems, and for which the organization has no direct control over the implementation of required controls or the assessment of control effectiveness. External systems include personally owned systems, components, or devices; privately owned computing and communications devices in commercial or public facilities; systems owned or controlled by nonfederal organizations; systems managed by contractors; and federal information systems that are not owned by, operated by, or under the direct supervision or authority of the organization. External systems also include systems owned or operated by other components within the same organization and systems within the organization with different authorization boundaries. Organizations have the option to prohibit the use of any type of external system or prohibit the use of specified types of external systems, (e.g., prohibit the use of any external system that is not organizationally owned or prohibit the use of personally-owned systems). For some external systems (i.e., systems operated by other organizations), the trust relationships that have been established between those organizations and the originating organization may be such that no explicit terms and conditions are required. Systems within these organizations may not be considered external. These situations occur when, for example, there are pre-existing information exchange agreements (either implicit or explicit) established between organizations or components or when such agreements are specified by applicable laws, executive orders, directives, regulations, policies, or standards. Authorized individuals include organizational personnel, contractors, or other individuals with authorized access to organizational systems and over which organizations have the authority to impose specific rules of behavior regarding system access. Restrictions that organizations impose on authorized individuals need not be uniform, as the restrictions may vary depending on trust relationships between organizations. Therefore, organizations may choose to impose different security restrictions on contractors than on state, local, or tribal governments. External systems used to access public interfaces to organizational systems are outside the scope of AC-20. Organizations establish specific terms and conditions for the use of external systems in accordance with organizational security policies and procedures. At a minimum, terms and conditions address the specific types of applications that can be accessed on organizational systems from external systems and the highest security category of information that can be processed, stored, or transmitted on external systems. If the terms and conditions with the owners of the external systems cannot be established, organizations may impose restrictions on organizational personnel using those external systems. AC-2, AC-3, AC-17, AC-19, CA-3, PL-2, PL-4, SA-9, SC-7. AC-3: Access Enforcement Enforce approved authorizations for logical access to information and system resources in accordance with applicable access control policies. AC-3 Access control policies control access between active entities or subjects (i.e., users or processes acting on behalf of users) and passive entities or objects (i.e., devices, files, records, domains) in organizational systems. In addition to enforcing authorized access at the system level and recognizing that systems can host many applications and services in support of mission and business functions, access enforcement mechanisms can also be employed at the application and service level to provide increased information security and privacy. In contrast to logical access controls that are implemented within the system, physical access controls are addressed by the controls in the Physical and Environmental Protection (PE) family. AC-2, AC-4, AC-5, AC-6, AC-16, AC-17, AC-18, AC-19, AC-20, AC-21, AC-22, AC-24, AC-25, AT-2, AT-3, AU-9, CA-9, CM-5, CM-11, IA-2, IA-5, IA-6, IA-7, IA-11, MA-3, MA-4, MA-5, MP-4, PM-2, PS-3, PT-2, PT-3, SA-17, SC-2, SC-3, SC-4, SC-12, SC-13, SC-28, SC-31, SC-34, SI-4, SI-8. AC-4: Information Flow Enforcement Enforce approved authorizations for controlling the flow of information within the system and between connected systems based on [Assignment: organization-defined information flow control policies]. AC-4 Information flow control regulates where information can travel within a system and between systems (in contrast to who is allowed to access the information) and without regard to subsequent accesses to that information. Flow control restrictions include blocking external traffic that claims to be from within the organization, keeping export-controlled information from being transmitted in the clear to the Internet, restricting web requests that are not from the internal web proxy server, and limiting information transfers between organizations based on data structures and content. Transferring information between organizations may require an agreement specifying how the information flow is enforced (see CA-3). Transferring information between systems in different security or privacy domains with different security or privacy policies introduces the risk that such transfers violate one or more domain security or privacy policies. In such situations, information owners/stewards provide guidance at designated policy enforcement points between connected systems. Organizations consider mandating specific architectural solutions to enforce specific security and privacy policies. Enforcement includes prohibiting information transfers between connected systems (i.e., allowing access only), verifying write permissions before accepting information from another security or privacy domain or connected system, employing hardware mechanisms to enforce one-way information flows, and implementing trustworthy regrading mechanisms to reassign security or privacy attributes and labels. Organizations commonly employ information flow control policies and enforcement mechanisms to control the flow of information between designated sources and destinations within systems and between connected systems. Flow control is based on the characteristics of the information and/or the information path. Enforcement occurs, for example, in boundary protection devices that employ rule sets or establish configuration settings that restrict system services, provide a packet-filtering capability based on header information, or provide a message-filtering capability based on message content. Organizations also consider the trustworthiness of filtering and/or inspection mechanisms (i.e., hardware, firmware, and software components) that are critical to information flow enforcement. Control enhancements 3 through 32 primarily address cross-domain solution needs that focus on more advanced filtering techniques, in-depth analysis, and stronger flow enforcement mechanisms implemented in cross-domain products, such as high-assurance guards. Such capabilities are generally not available in commercial off-the-shelf products. Information flow enforcement also applies to control plane traffic (e.g., routing and DNS). AC-3, AC-6, AC-16, AC-17, AC-19, AC-21, AU-10, CA-3, CA-9, CM-7, PL-9, PM-24, SA-17, SC-4, SC-7, SC-16, SC-31. AC-6: Least Privilege Employ the principle of least privilege, allowing only authorized accesses for users (or processes acting on behalf of users) that are necessary to accomplish assigned organizational tasks. AC-6 Organizations employ least privilege for specific duties and systems. The principle of least privilege is also applied to system processes, ensuring that the processes have access to systems and operate at privilege levels no higher than necessary to accomplish organizational missions or business functions. Organizations consider the creation of additional processes, roles, and accounts as necessary to achieve least privilege. Organizations apply least privilege to the development, implementation, and operation of organizational systems. AC-2, AC-3, AC-5, AC-16, CM-5, CM-11, PL-2, PM-12, SA-8, SA-15, SA-17, SC-38. AC-7: Unsuccessful Logon Attempts a. Enforce a limit of [Assignment: organization-defined number] consecutive invalid logon attempts by a user during a [Assignment: organization-defined time period]; and b. Automatically [Selection (one or more): lock the account or node for an [Assignment: organization-defined time period]; lock the account or node until released by an administrator; delay next logon prompt per [Assignment: organization-defined delay algorithm]; notify system administrator; take other [Assignment: organization-defined action]] when the maximum number of unsuccessful attempts is exceeded. AC-7 The need to limit unsuccessful logon attempts and take subsequent action when the maximum number of attempts is exceeded applies regardless of whether the logon occurs via a local or network connection. Due to the potential for denial of service, automatic lockouts initiated by systems are usually temporary and automatically release after a predetermined, organization-defined time period. If a delay algorithm is selected, organizations may employ different algorithms for different components of the system based on the capabilities of those components. Responses to unsuccessful logon attempts may be implemented at the operating system and the application levels. Organization-defined actions that may be taken when the number of allowed consecutive invalid logon attempts is exceeded include prompting the user to answer a secret question in addition to the username and password, invoking a lockdown mode with limited user capabilities (instead of full lockout), allowing users to only logon from specified Internet Protocol (IP) addresses, requiring a CAPTCHA to prevent automated attacks, or applying user profiles such as location, time of day, IP address, device, or Media Access Control (MAC) address. If automatic system lockout or execution of a delay algorithm is not implemented in support of the availability objective, organizations consider a combination of other actions to help prevent brute force attacks. In addition to the above, organizations can prompt users to respond to a secret question before the number of allowed unsuccessful logon attempts is exceeded. Automatically unlocking an account after a specified period of time is generally not permitted. However, exceptions may be required based on operational mission or need. AC-2, AC-9, AU-2, AU-6, IA-5. API consumer API supply chain compromise Custom threat (no CAPEC meta) AU-2: Event Logging a. Identify the types of events that the system is capable of logging in support of the audit function: [Assignment: organization-defined event types that the system is capable of logging]; b. Coordinate the event logging function with other organizational entities requiring audit-related information to guide and inform the selection criteria for events to be logged; c. Specify the following event types for logging within the system: [Assignment: organization-defined event types (subset of the event types defined in AU-2a.) along with the frequency of (or situation requiring) logging for each identified event type]; d. Provide a rationale for why the event types selected for logging are deemed to be adequate to support after-the-fact investigations of incidents; and e. Review and update the event types selected for logging [Assignment: organization-defined frequency]. AU-2 An event is an observable occurrence in a system. The types of events that require logging are those events that are significant and relevant to the security of systems and the privacy of individuals. Event logging also supports specific monitoring and auditing needs. Event types include password changes, failed logons or failed accesses related to systems, security or privacy attribute changes, administrative privilege usage, PIV credential usage, data action changes, query parameters, or external credential usage. In determining the set of event types that require logging, organizations consider the monitoring and auditing appropriate for each of the controls to be implemented. For completeness, event logging includes all protocols that are operational and supported by the system. To balance monitoring and auditing requirements with other system needs, event logging requires identifying the subset of event types that are logged at a given point in time. For example, organizations may determine that systems need the capability to log every file access successful and unsuccessful, but not activate that capability except for specific circumstances due to the potential burden on system performance. The types of events that organizations desire to be logged may change. Reviewing and updating the set of logged events is necessary to help ensure that the events remain relevant and continue to support the needs of the organization. Organizations consider how the types of logging events can reveal information about individuals that may give rise to privacy risk and how best to mitigate such risks. For example, there is the potential to reveal personally identifiable information in the audit trail, especially if the logging event is based on patterns or time of usage. Event logging requirements, including the need to log specific event types, may be referenced in other controls and control enhancements. These include AC-2(4), AC-3(10), AC-6(9), AC-17(1), CM-3f, CM-5(1), IA-3(3)(b), MA-4(1), MP-4(2), PE-3, PM-21, PT-7, RA-8, SC-7(9), SC-7(15), SI-3(8), SI-4(22), SI-7(8), and SI-10(1). Organizations include event types that are required by applicable laws, executive orders, directives, policies, regulations, standards, and guidelines. Audit records can be generated at various levels, including at the packet level as information traverses the network. Selecting the appropriate level of event logging is an important part of a monitoring and auditing capability and can identify the root causes of problems. When defining event types, organizations consider the logging necessary to cover related event types, such as the steps in distributed, transaction-based processes and the actions that occur in service-oriented architectures. AC-2, AC-3, AC-6, AC-7, AC-8, AC-16, AC-17, AU-3, AU-4, AU-5, AU-6, AU-7, AU-11, AU-12, CM-3, CM-5, CM-6, CM-13, IA-3, MA-4, MP-4, PE-3, PM-21, PT-2, PT-7, RA-8, SA-8, SC-7, SC-18, SI-3, SI-4, SI-7, SI-10, SI-11. Allowlisting Type: Syntax Verify data against a list or sequence of allowed characters Blocklisting Type: Syntax Data is checked against a list or sequence of known generic dangerous characters. CA-7: Continuous Monitoring Develop a system-level continuous monitoring strategy and implement continuous monitoring in accordance with the organization-level continuous monitoring strategy that includes: a. Establishing the following system-level metrics to be monitored: [Assignment: organization-defined system-level metrics]; b. Establishing [Assignment: organization-defined frequencies] for monitoring and [Assignment: organization-defined frequencies] for assessment of control effectiveness; c. Ongoing control assessments in accordance with the continuous monitoring strategy; d. Ongoing monitoring of system and organization-defined metrics in accordance with the continuous monitoring strategy; e. Correlation and analysis of information generated by control assessments and monitoring; f. Response actions to address results of the analysis of control assessment and monitoring information; and g. Reporting the security and privacy status of the system to [Assignment: organization-defined personnel or roles] [Assignment: organization-defined frequency]. CA-7 Continuous monitoring at the system level facilitates ongoing awareness of the system security and privacy posture to support organizational risk management decisions. The terms continuous and ongoing imply that organizations assess and monitor their controls and risks at a frequency sufficient to support risk-based decisions. Different types of controls may require different monitoring frequencies. The results of continuous monitoring generate risk response actions by organizations. When monitoring the effectiveness of multiple controls that have been grouped into capabilities, a root-cause analysis may be needed to determine the specific control that has failed. Continuous monitoring programs allow organizations to maintain the authorizations of systems and common controls in highly dynamic environments of operation with changing mission and business needs, threats, vulnerabilities, and technologies. Having access to security and privacy information on a continuing basis through reports and dashboards gives organizational officials the ability to make effective and timely risk management decisions, including ongoing authorization decisions. Automation supports more frequent updates to hardware, software, and firmware inventories, authorization packages, and other system information. Effectiveness is further enhanced when continuous monitoring outputs are formatted to provide information that is specific, measurable, actionable, relevant, and timely. Continuous monitoring activities are scaled in accordance with the security categories of systems. Monitoring requirements, including the need for specific monitoring, may be referenced in other controls and control enhancements, such as AC-2g, AC-2(7), AC-2(12)(a), AC-2(7)(b), AC-2(7)(c), AC-17(1), AT-4a, AU-13, AU-13(1), AU-13(2), CM-3f, CM-6d, CM-11c, IR-5, MA-2b, MA-3a, MA-4a, PE-3d, PE-6, PE-14b, PE-16, PE-20, PM-6, PM-23, PM-31, PS-7e, SA-9c, SR-4, SC-5(3)(b), SC-7a, SC-7(24)(b), SC-18b, SC-43b, and SI-4. AC-2, AC-6, AC-17, AT-4, AU-6, AU-13, CA-2, CA-5, CA-6, CM-3, CM-4, CM-6, CM-11, IA-5, IR-5, MA-2, MA-3, MA-4, PE-3, PE-6, PE-14, PE-16, PE-20, PL-2, PM-4, PM-6, PM-9, PM-10, PM-12, PM-14, PM-23, PM-28, PM-31, PS-7, PT-7, RA-3, RA-5, RA-7, RA-10, SA-8, SA-9, SA-11, SC-5, SC-7, SC-18, SC-38, SC-43, SI-3, SI-4, SI-12, SR-6. CAPEC-115: Authentication Bypass An attacker gains access to application, service, or device with the privileges of an authorized or privileged user by evading or circumventing an authentication mechanism. The attacker is therefore able to access protected data without authentication ever having taken place. CAPEC-115 115 Meta Draft Medium ::An authentication mechanism or subsystem implementing some form of authentication such as passwords, digest authentication, security certificates, etc.:: ::A client application, such as a web browser, or a scripting language capable of interacting with the target.:: ::287:: TAXONOMY NAME:ATTACK:ENTRY ID:1548:ENTRY NAME:Abuse Elevation Control Mechanism:: CAPEC-116: Excavation An adversary actively probes the target in a manner that is designed to solicit information that could be leveraged for malicious purposes. CAPEC-116 116 Meta Stable High Medium ::NATURE:CanPrecede:CAPEC ID:163:: ::An adversary requires some way of interacting with the system.:: ::A tool, such as an Adversary in the Middle (CAPEC-94) Proxy or a fuzzer, that is capable of generating and injecting custom inputs to be used in the attack.:: ::SCOPE:Confidentiality:TECHNICAL IMPACT:Read Data:: ::Minimize error/response output to only what is necessary for functional use or corrective language.::Remove potentially sensitive information that is not necessary for the application's functionality.:: ::200::1243:: TYPE:Other:NOTE:Large quantities of data is often moved from the target system to some other adversary controlled system. Data found on a target system might require extensive resources to be fully analyzed. Using these resources on the target system might enable a defender to detect the adversary. Additionally, proper analysis tools required might not be available on the target system.::::TYPE:Other:NOTE:This attack differs from Data Interception and other data collection attacks in that the attacker actively queries the target rather than simply watching for the target to reveal information.:: CAPEC-125: Flooding An adversary consumes the resources of a target by rapidly engaging in a large number of interactions with the target. This type of attack generally exposes a weakness in rate limiting or flow. When successful this attack prevents legitimate users from accessing the service and can cause the target to crash. This attack differs from resource depletion through leaks or allocations in that the latter attacks do not rely on the volume of requests made to the target but instead focus on manipulation of the target's operations. The key factor in a flooding attack is the number of requests the adversary can make in a given period of time. The greater this number, the more likely an attack is to succeed against a given target. CAPEC-125 125 Meta Stable High Medium ::Any target that services requests is vulnerable to this attack on some level of scale.:: ::A script or program capable of generating more requests than the target can handle, or a network or cluster of objects all capable of making simultaneous requests.:: ::SCOPE:Availability:TECHNICAL IMPACT:Unreliable Execution:TECHNICAL IMPACT:Resource Consumption:NOTE:A successful flooding attack compromises the availability of the target system's service by exhausting its available resources.:: ::Ensure that protocols have specific limits of scale configured.::Specify expectations for capabilities and dictate which behaviors are acceptable when resource allocation reaches limits.::Uniformly throttle all requests in order to make it more difficult to consume resources more quickly than they can again be freed.:: ::404::770:: TAXONOMY NAME:ATTACK:ENTRY ID:1498.001:ENTRY NAME:Network Denial of Service: Direct Network Flood::::TAXONOMY NAME:ATTACK:ENTRY ID:1499:ENTRY NAME:Endpoint Denial of Service::::TAXONOMY NAME:WASC:ENTRY ID:10:ENTRY NAME:Denial of Service::::TAXONOMY NAME:OWASP Attacks:ENTRY NAME:Traffic flood:: CAPEC-169: Footprinting An adversary engages in probing and exploration activities to identify constituents and properties of the target. CAPEC-169 169 Meta Stable High Very Low ::STEP:1:PHASE:Explore:DESCRIPTION:[Request Footprinting] The attacker examines the website information and source code of the website and uses automated tools to get as much information as possible about the system and organization.:TECHNIQUE:Open Source Footprinting: Examine the website about the organization and skim through the webpage's HTML source to look for comments.:TECHNIQUE:Network Enumeration: Perform various queries (Registrar Query, Organizational Query, Domain Query, Network Query, POC Query) on the many whois databases found on the internet to identify domain names and associated networks.:TECHNIQUE:DNS Interrogation: Once basic information is gathered the attack could begin to query DNS.:TECHNIQUE:Other Techniques: Use ping sweep, TCP scan, UDP scan, OS Identification various techniques to gain more information about the system and network.:: ::An application must publicize identifiable information about the system or application through voluntary or involuntary means. Certain identification details of information systems are visible on communication networks (e.g., if an adversary uses a sniffer to inspect the traffic) due to their inherent structure and protocol standards. Any system or network that can be detected can be footprinted. However, some configuration choices may limit the useful information that can be collected during a footprinting attack.:: ::SKILL:The adversary knows how to send HTTP request, run the scan tool.:LEVEL:Low:: ::The adversary requires a variety of tools to collect information about the target. These include port/network scanners and tools to analyze responses from applications to determine version and configuration information. Footprinting a system adequately may also take a few days if the attacker wishes the footprinting attempt to go undetected.:: ::SCOPE:Confidentiality:TECHNICAL IMPACT:Read Data:: ::Keep patches up to date by installing weekly or daily if possible.::Shut down unnecessary services/ports.::Change default passwords by choosing strong passwords.::Curtail unexpected input.::Encrypt and password-protect sensitive data.::Avoid including information that has the potential to identify and compromise your organization's security such as access to business plans, formulas, and proprietary documents.:: ::In this example let us look at the website http://www.example.com to get much information we can about Alice. From the website, we find that Alice also runs foobar.org. We type in www example.com into the prompt of the Name Lookup window in a tool, and our result is this IP address: 192.173.28.130 We type the domain into the Name Lookup prompt and we are given the same IP. We can safely say that example and foobar.org are hosted on the same box. But if we were to do a reverse name lookup on the IP, which domain will come up? www.example.com or foobar.org? Neither, the result is nijasvspirates.org. So nijasvspirates.org is the name of the box hosting 31337squirrel.org and foobar.org. So now that we have the IP, let's check to see if nijasvspirates is awake. We type the IP into the prompt in the Ping window. We'll set the interval between packets to 1 millisecond. We'll set the number of seconds to wait until a ping times out to 5. We'll set the ping size to 500 bytes and we'll send ten pings. Ten packets sent and ten packets received. nijasvspirates.org returned a message to my computer within an average of 0.35 seconds for every packet sent. nijasvspirates is alive. We open the Whois window and type nijasvspirates.org into the Query prompt, and whois.networksolutions.com into the Server prompt. This means we'll be asking Network Solutions to tell us everything they know about nijasvspirates.org. The result is this laundry list of info: Registrant: FooBar (nijasvspirates -DOM) p.o.box 11111 SLC, UT 84151 US Domain Name: nijasvspirates.ORG Administrative Contact, Billing Contact: Smith, John jsmith@anonymous.net FooBar p.o.box 11111 SLC, UT 84151 555-555-6103 Technical Contact: Johnson, Ken kj@fierymonkey.org fierymonkey p.o.box 11111 SLC, UT 84151 555-555-3849 Record last updated on 17-Aug-2001. Record expires on 11-Aug-2002. Record created on 11-Aug-2000. Database last updated on 12-Dec-2001 04:06:00 EST. Domain servers in listed order: NS1. fierymonkey.ORG 192.173.28.130 NS2. fierymonkey.ORG 64.192.168.80 A corner stone of footprinting is Port Scanning. Let's port scan nijasvspirates.org and see what kind of services are running on that box. We type in the nijasvspirates IP into the Host prompt of the Port Scan window. We'll start searching from port number 1, and we'll stop at the default Sub7 port, 27374. Our results are: 21 TCP ftp 22 TCP ssh SSH-1.99-OpenSSH_2.30 25 TCP smtp 53 TCP domain 80 TCP www 110 TCP pop3 111 TCP sunrpc 113 TCP ident Just by this we know that Alice is running a website and email, using POP3, SUNRPC (SUN Remote Procedure Call), and ident.:: ::200:: TAXONOMY NAME:ATTACK:ENTRY ID:1217:ENTRY NAME:Browser Bookmark Discovery::::TAXONOMY NAME:ATTACK:ENTRY ID:1592:ENTRY NAME:Gather Victim Host Information::::TAXONOMY NAME:ATTACK:ENTRY ID:1595:ENTRY NAME:Active Scanning:: CAPEC-21: Exploitation of Trusted Identifiers An adversary guesses, obtains, or rides a trusted identifier (e.g. session ID, resource ID, cookie, etc.) to perform authorized actions under the guise of an authenticated user or service. CAPEC-21 21 Meta Stable High High ::STEP:1:PHASE:Explore:DESCRIPTION:[Survey the application for Indicators of Susceptibility] Using a variety of methods, until one is found that applies to the target, the adversary probes for cookies, session tokens, or entry points that bypass identifiers altogether.:TECHNIQUE:Spider all available pages:TECHNIQUE:Attack known bad interfaces:TECHNIQUE:Search outward-facing configuration and properties files for identifiers.::STEP:2:PHASE:Experiment:DESCRIPTION:[Fetch samples] The adversary fetches many samples of identifiers. This may be through legitimate access (logging in, legitimate connections, etc.) or via systematic probing.:TECHNIQUE:An adversary makes many anonymous connections and records the session IDs assigned.:TECHNIQUE:An adversary makes authorized connections and records the session tokens or credentials issued.:TECHNIQUE:An adversary gains access to (legitimately or illegitimately) a nearby system (e.g., in the same operations network, DMZ, or local network) and makes a connection from it, attempting to gain the same privileges as a trusted system.::STEP:3:PHASE:Exploit:DESCRIPTION:[Impersonate] An adversary can use successful experiments or authentications to impersonate an authorized user or system or to laterally move within a system or application::STEP:4:PHASE:Exploit:DESCRIPTION:[Spoofing] Malicious data can be injected into the target system or into a victim user's system by an adversary. The adversary can also pose as a legitimate user to perform social engineering attacks.::STEP:5:PHASE:Exploit:DESCRIPTION:[Data Exfiltration] The adversary can obtain sensitive data contained within the system or application.:: ::Server software must rely on weak identifier proof and/or verification schemes.::Identifiers must have long lifetimes and potential for reusability.::Server software must allow concurrent sessions to exist.:: ::SKILL:To achieve a direct connection with the weak or non-existent server session access control, and pose as an authorized user:LEVEL:Low:: ::Ability to deploy software on network.::Ability to communicate synchronously or asynchronously with server.:: ::SCOPE:Confidentiality:SCOPE:Access Control:SCOPE:Authentication:TECHNICAL IMPACT:Gain Privileges::SCOPE:Confidentiality:TECHNICAL IMPACT:Read Data::SCOPE:Integrity:TECHNICAL IMPACT:Modify Data:: ::Design: utilize strong federated identity such as SAML to encrypt and sign identity tokens in transit.::Implementation: Use industry standards session key generation mechanisms that utilize high amount of entropy to generate the session key. Many standard web and application servers will perform this task on your behalf.::Implementation: If the identifier is used for authentication, such as in the so-called single sign on use cases, then ensure that it is protected at the same level of assurance as authentication tokens.::Implementation: If the web or application server supports it, then encrypting and/or signing the identifier (such as cookie) can protect the ID if intercepted.::Design: Use strong session identifiers that are protected in transit and at rest.::Implementation: Utilize a session timeout for all sessions, for example 20 minutes. If the user does not explicitly logout, the server terminates their session after this period of inactivity. If the user logs back in then a new session key is generated.::Implementation: Verify authenticity of all identifiers at runtime.:: ::Thin client applications like web applications are particularly vulnerable to session ID attacks. Since the server has very little control over the client, but still must track sessions, data, and objects on the server side, cookies and other mechanisms have been used to pass the key to the session data between the client and server. When these session keys are compromised it is trivial for an adversary to impersonate a user's session in effect, have the same capabilities as the authorized user. There are two main ways for an adversary to exploit session IDs. A brute force attack involves an adversary repeatedly attempting to query the system with a spoofed session header in the HTTP request. A web server that uses a short session ID can be easily spoofed by trying many possible combinations so the parameters session-ID= 1234 has few possible combinations, and an adversary can retry several hundred or thousand request with little to no issue on their side. The second method is interception, where a tool such as wireshark is used to sniff the wire and pull off any unprotected session identifiers. The adversary can then use these variables and access the application.::For example, in a message queuing system that allows service requesters to post messages to its queue through an open channel (such as anonymous FTP), authorization is done through checking group or role membership contained in the posted message. However, there is no proof that the message itself, the information in the message (such group or role membership), or the process that wrote the message to the queue is authentic and authorized to do so.:: ::290::302::346::539::6::384::664::602::642:: TAXONOMY NAME:ATTACK:ENTRY ID:1134:ENTRY NAME:Access Token Manipulation::::TAXONOMY NAME:ATTACK:ENTRY ID:1528:ENTRY NAME:Steal Application Access Token::::TAXONOMY NAME:ATTACK:ENTRY ID:1539:ENTRY NAME:Steal Web Session Cookie:: CAPEC-242: Code Injection An adversary exploits a weakness in input validation on the target to inject new code into that which is currently executing. This differs from code inclusion in that code inclusion involves the addition or replacement of a reference to a code file, which is subsequently loaded by the target and used as part of the code of some application. CAPEC-242 242 Meta Stable High High ::The target software does not validate user-controlled input such that the execution of a process may be altered by sending code in through legitimate data channels, using no other mechanism.:: ::SCOPE:Confidentiality:SCOPE:Integrity:SCOPE:Availability:TECHNICAL IMPACT:Other:NOTE:Code Injection attack patterns can result in a wide variety of consequences and negatively affect all three elements of the security triad.:: ::Utilize strict type, character, and encoding enforcement::Ensure all input content that is delivered to client is sanitized against an acceptable content specification.::Perform input validation for all content.::Enforce regular patching of software.:: ::94:: TAXONOMY NAME:OWASP Attacks:ENTRY NAME:Code Injection:: CAPEC-94: Adversary in the Middle (AiTM) An adversary targets the communication between two components (typically client and server), in order to alter or obtain data from transactions. A general approach entails the adversary placing themself within the communication channel between the two components. CAPEC-94 94 Meta Stable ::TERM:Man-in-the-Middle / MITM:DESCRIPTION:::TERM:Person-in-the-Middle / PiTM:DESCRIPTION:::TERM:Monkey-in-the-Middle:DESCRIPTION:::TERM:Monster-in-the-Middle:DESCRIPTION:::TERM:On-path Attacker:DESCRIPTION::: High Very High ::NATURE:CanPrecede:CAPEC ID:151::NATURE:CanPrecede:CAPEC ID:668:: ::STEP:1:PHASE:Explore:DESCRIPTION:[Determine Communication Mechanism] The adversary determines the nature and mechanism of communication between two components, looking for opportunities to exploit.:TECHNIQUE:Perform a sniffing attack and observe communication to determine a communication protocol.:TECHNIQUE:Look for application documentation that might describe a communication mechanism used by a target.::STEP:2:PHASE:Experiment:DESCRIPTION:[Position In Between Targets] The adversary inserts themself into the communication channel initially acting as a routing proxy between the two targeted components.:TECHNIQUE:Install spyware on a client that will intercept outgoing packets and route them to their destination as well as route incoming packets back to the client.:TECHNIQUE:Exploit a weakness in an encrypted communication mechanism to gain access to traffic. Look for outdated mechanisms such as SSL.::STEP:3:PHASE:Exploit:DESCRIPTION:[Use Intercepted Data Maliciously] The adversary observes, filters, or alters passed data of its choosing to gain access to sensitive information or to manipulate the actions of the two target components for their own purposes.:TECHNIQUE:Prevent some messages from reaching their destination, causing a denial of service.:: ::There are two components communicating with each other.::An attacker is able to identify the nature and mechanism of communication between the two target components.::An attacker can eavesdrop on the communication between the target components.::Strong mutual authentication is not used between the two target components yielding opportunity for attacker interposition.::The communication occurs in clear (not encrypted) or with insufficient and spoofable encryption.:: ::SKILL:This attack can get sophisticated since the attack may use cryptography.:LEVEL:Medium:: ::SCOPE:Integrity:TECHNICAL IMPACT:Modify Data::SCOPE:Confidentiality:SCOPE:Access Control:SCOPE:Authorization:TECHNICAL IMPACT:Gain Privileges::SCOPE:Confidentiality:TECHNICAL IMPACT:Read Data:: ::Ensure Public Keys are signed by a Certificate Authority::Encrypt communications using cryptography (e.g., SSL/TLS)::Use Strong mutual authentication to always fully authenticate both ends of any communications channel.::Exchange public keys using a secure channel:: ::In 2017, security researcher Jerry Decime discovered that Equifax mobile applications were not leveraging HTTPS in all areas. Although authentication was properly utilizing HTTPS, in addition to validating the root of trust of the server certificate, other areas of the application were using HTTP to communicate. Adversaries could then conduct MITM attacks on rogue WiFi or cellular networks and hijack the UX. This further allowed the adversaries to prompt users for sensitive data, which could then be obtained in the plaintext response. [REF-636]:: ::300::290::593::287::294:: TAXONOMY NAME:ATTACK:ENTRY ID:1557:ENTRY NAME:Adversary-in-the-Middle::::TAXONOMY NAME:OWASP Attacks:ENTRY NAME:Man-in-the-middle attack:: CM-2: Baseline Configuration a. Develop, document, and maintain under configuration control, a current baseline configuration of the system; and b. Review and update the baseline configuration of the system: 1. [Assignment: organization-defined frequency]; 2. When required due to [Assignment: organization-defined circumstances]; and 3. When system components are installed or upgraded. CM-2 Baseline configurations for systems and system components include connectivity, operational, and communications aspects of systems. Baseline configurations are documented, formally reviewed, and agreed-upon specifications for systems or configuration items within those systems. Baseline configurations serve as a basis for future builds, releases, or changes to systems and include security and privacy control implementations, operational procedures, information about system components, network topology, and logical placement of components in the system architecture. Maintaining baseline configurations requires creating new baselines as organizational systems change over time. Baseline configurations of systems reflect the current enterprise architecture. AC-19, AU-6, CA-9, CM-1, CM-3, CM-5, CM-6, CM-8, CM-9, CP-9, CP-10, CP-12, MA-2, PL-8, PM-5, SA-8, SA-10, SA-15, SC-18. CM-3: Configuration Change Control a. Determine and document the types of changes to the system that are configuration-controlled; b. Review proposed configuration-controlled changes to the system and approve or disapprove such changes with explicit consideration for security and privacy impact analyses; c. Document configuration change decisions associated with the system; d. Implement approved configuration-controlled changes to the system; e. Retain records of configuration-controlled changes to the system for [Assignment: organization-defined time period]; f. Monitor and review activities associated with configuration-controlled changes to the system; and g. Coordinate and provide oversight for configuration change control activities through [Assignment: organization-defined configuration change control element] that convenes [Selection (one or more): [Assignment: organization-defined frequency]; when [Assignment: organization-defined configuration change conditions]]. CM-3 Configuration change control for organizational systems involves the systematic proposal, justification, implementation, testing, review, and disposition of system changes, including system upgrades and modifications. Configuration change control includes changes to baseline configurations, configuration items of systems, operational procedures, configuration settings for system components, remediate vulnerabilities, and unscheduled or unauthorized changes. Processes for managing configuration changes to systems include Configuration Control Boards or Change Advisory Boards that review and approve proposed changes. For changes that impact privacy risk, the senior agency official for privacy updates privacy impact assessments and system of records notices. For new systems or major upgrades, organizations consider including representatives from the development organizations on the Configuration Control Boards or Change Advisory Boards. Auditing of changes includes activities before and after changes are made to systems and the auditing activities required to implement such changes. See also SA-10. CA-7, CM-2, CM-4, CM-5, CM-6, CM-9, CM-11, IA-3, MA-2, PE-16, PT-6, RA-8, SA-8, SA-10, SC-28, SC-34, SC-37, SI-2, SI-3, SI-4, SI-7, SI-10, SR-11. CM-7: Least Functionality a. Configure the system to provide only [Assignment: organization-defined mission essential capabilities]; and b. Prohibit or restrict the use of the following functions, ports, protocols, software, and/or services: [Assignment: organization-defined prohibited or restricted functions, system ports, protocols, software, and/or services]. CM-7 Systems provide a wide variety of functions and services. Some of the functions and services routinely provided by default may not be necessary to support essential organizational missions, functions, or operations. Additionally, it is sometimes convenient to provide multiple services from a single system component, but doing so increases risk over limiting the services provided by that single component. Where feasible, organizations limit component functionality to a single function per component. Organizations consider removing unused or unnecessary software and disabling unused or unnecessary physical and logical ports and protocols to prevent unauthorized connection of components, transfer of information, and tunneling. Organizations employ network scanning tools, intrusion detection and prevention systems, and end-point protection technologies, such as firewalls and host-based intrusion detection systems, to identify and prevent the use of prohibited functions, protocols, ports, and services. Least functionality can also be achieved as part of the fundamental design and development of the system (see SA-8, SC-2, and SC-3). AC-3, AC-4, CM-2, CM-5, CM-6, CM-11, RA-5, SA-4, SA-5, SA-8, SA-9, SA-15, SC-2, SC-3, SC-7, SC-37, SI-4. CM-8: System Component Inventory a. Develop and document an inventory of system components that: 1. Accurately reflects the system; 2. Includes all components within the system; 3. Does not include duplicate accounting of components or components assigned to any other system; 4. Is at the level of granularity deemed necessary for tracking and reporting; and 5. Includes the following information to achieve system component accountability: [Assignment: organization-defined information deemed necessary to achieve effective system component accountability]; and b. Review and update the system component inventory [Assignment: organization-defined frequency]. CM-8 System components are discrete, identifiable information technology assets that include hardware, software, and firmware. Organizations may choose to implement centralized system component inventories that include components from all organizational systems. In such situations, organizations ensure that the inventories include system-specific information required for component accountability. The information necessary for effective accountability of system components includes the system name, software owners, software version numbers, hardware inventory specifications, software license information, and for networked components, the machine names and network addresses across all implemented protocols (e.g., IPv4, IPv6). Inventory specifications include date of receipt, cost, model, serial number, manufacturer, supplier information, component type, and physical location. Preventing duplicate accounting of system components addresses the lack of accountability that occurs when component ownership and system association is not known, especially in large or complex connected systems. Effective prevention of duplicate accounting of system components necessitates use of a unique identifier for each component. For software inventory, centrally managed software that is accessed via other systems is addressed as a component of the system on which it is installed and managed. Software installed on multiple organizational systems and managed at the system level is addressed for each individual system and may appear more than once in a centralized component inventory, necessitating a system association for each software instance in the centralized inventory to avoid duplicate accounting of components. Scanning systems implementing multiple network protocols (e.g., IPv4 and IPv6) can result in duplicate components being identified in different address spaces. The implementation of CM-8(7) can help to eliminate duplicate accounting of components. CM-2, CM-7, CM-9, CM-10, CM-11, CM-13, CP-2, CP-9, MA-2, MA-6, PE-20, PL-9, PM-5, SA-4, SA-5, SI-2, SR-4. Data sanitization Focusses on disarming the data so it can’t damage the system. Disarming data is expected to occur in the context where the data will be processed Data store Detailed validation Type: Syntax & semantic Validate multiple properties of the data. It must check for the: • syntactical data correctness (e.g. validating the data type and length); • semantical data correctness to ensure it meets the business context (e.g. validating the format, pattern and range). Exploit hardware or platform vulnerabilities Custom threat (no CAPEC meta) IA-2: Identification and Authentication (organizational Users) Uniquely identify and authenticate organizational users and associate that unique identification with processes acting on behalf of those users. IA-2 Organizations can satisfy the identification and authentication requirements by complying with the requirements in HSPD 12. Organizational users include employees or individuals who organizations consider to have an equivalent status to employees (e.g., contractors and guest researchers). Unique identification and authentication of users applies to all accesses other than those that are explicitly identified in AC-14 and that occur through the authorized use of group authenticators without individual authentication. Since processes execute on behalf of groups and roles, organizations may require unique identification of individuals in group accounts or for detailed accountability of individual activity. Organizations employ passwords, physical authenticators, or biometrics to authenticate user identities or, in the case of multi-factor authentication, some combination thereof. Access to organizational systems is defined as either local access or network access. Local access is any access to organizational systems by users or processes acting on behalf of users, where access is obtained through direct connections without the use of networks. Network access is access to organizational systems by users (or processes acting on behalf of users) where access is obtained through network connections (i.e., nonlocal accesses). Remote access is a type of network access that involves communication through external networks. Internal networks include local area networks and wide area networks. The use of encrypted virtual private networks for network connections between organization-controlled endpoints and non-organization-controlled endpoints may be treated as internal networks with respect to protecting the confidentiality and integrity of information traversing the network. Identification and authentication requirements for non-organizational users are described in IA-8. AC-2, AC-3, AC-4, AC-14, AC-17, AC-18, AU-1, AU-6, IA-4, IA-5, IA-8, MA-4, MA-5, PE-2, PL-4, SA-4, SA-8. IA-4: Identifier Management Manage system identifiers by: a. Receiving authorization from [Assignment: organization-defined personnel or roles] to assign an individual, group, role, service, or device identifier; b. Selecting an identifier that identifies an individual, group, role, service, or device; c. Assigning the identifier to the intended individual, group, role, service, or device; and d. Preventing reuse of identifiers for [Assignment: organization-defined time period]. IA-4 Common device identifiers include Media Access Control (MAC) addresses, Internet Protocol (IP) addresses, or device-unique token identifiers. The management of individual identifiers is not applicable to shared system accounts. Typically, individual identifiers are the usernames of the system accounts assigned to those individuals. In such instances, the account management activities of AC-2 use account names provided by IA-4. Identifier management also addresses individual identifiers not necessarily associated with system accounts. Preventing the reuse of identifiers implies preventing the assignment of previously used individual, group, role, service, or device identifiers to different individuals, groups, roles, services, or devices. AC-5, IA-2, IA-3, IA-5, IA-8, IA-9, IA-12, MA-4, PE-2, PE-3, PE-4, PL-4, PM-12, PS-3, PS-4, PS-5, SC-37. IA-5: Authenticator Management Manage system authenticators by: a. Verifying, as part of the initial authenticator distribution, the identity of the individual, group, role, service, or device receiving the authenticator; b. Establishing initial authenticator content for any authenticators issued by the organization; c. Ensuring that authenticators have sufficient strength of mechanism for their intended use; d. Establishing and implementing administrative procedures for initial authenticator distribution, for lost or compromised or damaged authenticators, and for revoking authenticators; e. Changing default authenticators prior to first use; f. Changing or refreshing authenticators [Assignment: organization-defined time period by authenticator type] or when [Assignment: organization-defined events] occur; g. Protecting authenticator content from unauthorized disclosure and modification; h. Requiring individuals to take, and having devices implement, specific controls to protect authenticators; and i. Changing authenticators for group or role accounts when membership to those accounts changes. IA-5 Authenticators include passwords, cryptographic devices, biometrics, certificates, one-time password devices, and ID badges. Device authenticators include certificates and passwords. Initial authenticator content is the actual content of the authenticator (e.g., the initial password). In contrast, the requirements for authenticator content contain specific criteria or characteristics (e.g., minimum password length). Developers may deliver system components with factory default authentication credentials (i.e., passwords) to allow for initial installation and configuration. Default authentication credentials are often well known, easily discoverable, and present a significant risk. The requirement to protect individual authenticators may be implemented via control PL-4 or PS-6 for authenticators in the possession of individuals and by controls AC-3, AC-6, and SC-28 for authenticators stored in organizational systems, including passwords stored in hashed or encrypted formats or files containing encrypted or hashed passwords accessible with administrator privileges. Systems support authenticator management by organization-defined settings and restrictions for various authenticator characteristics (e.g., minimum password length, validation time window for time synchronous one-time tokens, and number of allowed rejections during the verification stage of biometric authentication). Actions can be taken to safeguard individual authenticators, including maintaining possession of authenticators, not sharing authenticators with others, and immediately reporting lost, stolen, or compromised authenticators. Authenticator management includes issuing and revoking authenticators for temporary access when no longer needed. AC-3, AC-6, CM-6, IA-2, IA-4, IA-7, IA-8, IA-9, MA-4, PE-2, PL-4, SC-12, SC-13. IA-8: Identification and Authentication (non-organizational Users) Uniquely identify and authenticate non-organizational users or processes acting on behalf of non-organizational users. IA-8 Non-organizational users include system users other than organizational users explicitly covered by IA-2. Non-organizational users are uniquely identified and authenticated for accesses other than those explicitly identified and documented in AC-14. Identification and authentication of non-organizational users accessing federal systems may be required to protect federal, proprietary, or privacy-related information (with exceptions noted for national security systems). Organizations consider many factors—including security, privacy, scalability, and practicality—when balancing the need to ensure ease of use for access to federal information and systems with the need to protect and adequately mitigate risk. AC-2, AC-6, AC-14, AC-17, AC-18, AU-6, IA-2, IA-4, IA-5, IA-10, IA-11, MA-4, RA-3, SA-4, SC-8. IA-9: Service Identification and Authentication Uniquely identify and authenticate [Assignment: organization-defined system services and applications] before establishing communications with devices, users, or other services or applications. IA-9 Services that may require identification and authentication include web applications using digital certificates or services or applications that query a database. Identification and authentication methods for system services and applications include information or code signing, provenance graphs, and electronic signatures that indicate the sources of services. Decisions regarding the validity of identification and authentication claims can be made by services separate from the services acting on those decisions. This can occur in distributed system architectures. In such situations, the identification and authentication decisions (instead of actual identifiers and authentication data) are provided to the services that need to act on those decisions. IA-3, IA-4, IA-5, SC-8. Mobile NORA-1: External NORA-1 This domain encompasses everything that falls outside the direct protection and management of an organization and should therefore be considered untrusted. Various communication channels to the external world can be established from within an organization: connections to an untrusted zone, a semi-trusted zone, a trusted zone, and a highly trusted zone. For example, if an organization's IT management is entirely outsourced, a highly trusted channel is required to the management service provider. This channel is also needed for exchanging highly confidential information between organizations. Organizations that fully trust each other implement mutual measures and maintain security levels to ensure that only limited border protection is needed at the connection point. Organizations that exchange information at a semi-trusted level also take these measures, requiring limited border protection. In summary, the strictness of measures for connecting to untrusted zones mainly focuses on border protection in the communication channel. When connecting trusted zones, the emphasis is primarily on protective measures within the channel itself (the strength of the tunnel). NORA-2: DMZ (Demilitarized Zone) NORA-2 This domain is a neutral area between the external world and the organization, primarily serving as a relay. The external side of a DMZ is formed by border protection with strong filtering functions. Within the DMZ, mechanisms exist for protocol filtering and blocking unwanted communications, as well as functionalities for decoupling (proxies), protocol transformation, hacker deception, and monitoring. In many cases, the DMZ also contains web servers that hold publicly accessible organizational data. The security level is semi-trusted because the data in a DMZ must, in the worst case, be considered disposable. If the external border protection is breached, a hacker could gain access to the data within the DMZ. The filtering mechanisms and the border protection between the DMZ and the organization must prevent hackers from progressing from the DMZ to trusted domains. NORA-4: Back Office NORA-4 This zone contains both supporting systems for the front office and systems used to populate business-critical systems located in the data zone. The back office is a trusted domain where applications essential for the organization's normal business operations run. RA-5: Vulnerability Monitoring and Scanning a. Monitor and scan for vulnerabilities in the system and hosted applications [Assignment: organization-defined frequency and/or randomly in accordance with organization-defined process] and when new vulnerabilities potentially affecting the system are identified and reported; b. Employ vulnerability monitoring tools and techniques that facilitate interoperability among tools and automate parts of the vulnerability management process by using standards for: 1. Enumerating platforms, software flaws, and improper configurations; 2. Formatting checklists and test procedures; and 3. Measuring vulnerability impact; c. Analyze vulnerability scan reports and results from vulnerability monitoring; d. Remediate legitimate vulnerabilities [Assignment: organization-defined response times] in accordance with an organizational assessment of risk; e. Share information obtained from the vulnerability monitoring process and control assessments with [Assignment: organization-defined personnel or roles] to help eliminate similar vulnerabilities in other systems; and f. Employ vulnerability monitoring tools that include the capability to readily update the vulnerabilities to be scanned. RA-5 Security categorization of information and systems guides the frequency and comprehensiveness of vulnerability monitoring (including scans). Organizations determine the required vulnerability monitoring for system components, ensuring that the potential sources of vulnerabilities—such as infrastructure components (e.g., switches, routers, guards, sensors), networked printers, scanners, and copiers—are not overlooked. The capability to readily update vulnerability monitoring tools as new vulnerabilities are discovered and announced and as new scanning methods are developed helps to ensure that new vulnerabilities are not missed by employed vulnerability monitoring tools. The vulnerability monitoring tool update process helps to ensure that potential vulnerabilities in the system are identified and addressed as quickly as possible. Vulnerability monitoring and analyses for custom software may require additional approaches, such as static analysis, dynamic analysis, binary analysis, or a hybrid of the three approaches. Organizations can use these analysis approaches in source code reviews and in a variety of tools, including web-based application scanners, static analysis tools, and binary analyzers. Vulnerability monitoring includes scanning for patch levels; scanning for functions, ports, protocols, and services that should not be accessible to users or devices; and scanning for flow control mechanisms that are improperly configured or operating incorrectly. Vulnerability monitoring may also include continuous vulnerability monitoring tools that use instrumentation to continuously analyze components. Instrumentation-based tools may improve accuracy and may be run throughout an organization without scanning. Vulnerability monitoring tools that facilitate interoperability include tools that are Security Content Automated Protocol (SCAP)-validated. Thus, organizations consider using scanning tools that express vulnerabilities in the Common Vulnerabilities and Exposures (CVE) naming convention and that employ the Open Vulnerability Assessment Language (OVAL) to determine the presence of vulnerabilities. Sources for vulnerability information include the Common Weakness Enumeration (CWE) listing and the National Vulnerability Database (NVD). Control assessments, such as red team exercises, provide additional sources of potential vulnerabilities for which to scan. Organizations also consider using scanning tools that express vulnerability impact by the Common Vulnerability Scoring System (CVSS). Vulnerability monitoring includes a channel and process for receiving reports of security vulnerabilities from the public at-large. Vulnerability disclosure programs can be as simple as publishing a monitored email address or web form that can receive reports, including notification authorizing good-faith research and disclosure of security vulnerabilities. Organizations generally expect that such research is happening with or without their authorization and can use public vulnerability disclosure channels to increase the likelihood that discovered vulnerabilities are reported directly to the organization for remediation. Organizations may also employ the use of financial incentives (also known as bug bounties) to further encourage external security researchers to report discovered vulnerabilities. Bug bounty programs can be tailored to the organization’s needs. Bounties can be operated indefinitely or over a defined period of time and can be offered to the general public or to a curated group. Organizations may run public and private bounties simultaneously and could choose to offer partially credentialed access to certain participants in order to evaluate security vulnerabilities from privileged vantage points. CA-2, CA-7, CA-8, CM-2, CM-4, CM-6, CM-8, RA-2, RA-3, SA-11, SA-15, SC-38, SI-2, SI-3, SI-4, SI-7, SR-11. SA-11: Developer Testing and Evaluation Require the developer of the system, system component, or system service, at all post-design stages of the system development life cycle, to: a. Develop and implement a plan for ongoing security and privacy control assessments; b. Perform [Selection (one or more): unit; integration; system; regression] testing/evaluation [Assignment: organization-defined frequency] at [Assignment: organization-defined depth and coverage]; c. Produce evidence of the execution of the assessment plan and the results of the testing and evaluation; d. Implement a verifiable flaw remediation process; and e. Correct flaws identified during testing and evaluation. SA-11 Developmental testing and evaluation confirms that the required controls are implemented correctly, operating as intended, enforcing the desired security and privacy policies, and meeting established security and privacy requirements. Security properties of systems and the privacy of individuals may be affected by the interconnection of system components or changes to those components. The interconnections or changes—including upgrading or replacing applications, operating systems, and firmware—may adversely affect previously implemented controls. Ongoing assessment during development allows for additional types of testing and evaluation that developers can conduct to reduce or eliminate potential flaws. Testing custom software applications may require approaches such as manual code review, security architecture review, and penetration testing, as well as and static analysis, dynamic analysis, binary analysis, or a hybrid of the three analysis approaches. Developers can use the analysis approaches, along with security instrumentation and fuzzing, in a variety of tools and in source code reviews. The security and privacy assessment plans include the specific activities that developers plan to carry out, including the types of analyses, testing, evaluation, and reviews of software and firmware components; the degree of rigor to be applied; the frequency of the ongoing testing and evaluation; and the types of artifacts produced during those processes. The depth of testing and evaluation refers to the rigor and level of detail associated with the assessment process. The coverage of testing and evaluation refers to the scope (i.e., number and type) of the artifacts included in the assessment process. Contracts specify the acceptance criteria for security and privacy assessment plans, flaw remediation processes, and the evidence that the plans and processes have been diligently applied. Methods for reviewing and protecting assessment plans, evidence, and documentation are commensurate with the security category or classification level of the system. Contracts may specify protection requirements for documentation. CA-2, CA-7, CM-4, SA-3, SA-4, SA-5, SA-8, SA-15, SA-17, SI-2, SR-5, SR-6, SR-7. SC-13: Cryptographic Protection a. Determine the [Assignment: organization-defined cryptographic uses]; and b. Implement the following types of cryptography required for each specified cryptographic use: [Assignment: organization-defined types of cryptography for each specified cryptographic use]. SC-13 Cryptography can be employed to support a variety of security solutions, including the protection of classified information and controlled unclassified information, the provision and implementation of digital signatures, and the enforcement of information separation when authorized individuals have the necessary clearances but lack the necessary formal access approvals. Cryptography can also be used to support random number and hash generation. Generally applicable cryptographic standards include FIPS-validated cryptography and NSA-approved cryptography. For example, organizations that need to protect classified information may specify the use of NSA-approved cryptography. Organizations that need to provision and implement digital signatures may specify the use of FIPS-validated cryptography. Cryptography is implemented in accordance with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines. AC-2, AC-3, AC-7, AC-17, AC-18, AC-19, AU-9, AU-10, CM-11, CP-9, IA-3, IA-5, IA-7, MA-4, MP-2, MP-4, MP-5, SA-4, SA-8, SA-9, SC-8, SC-12, SC-20, SC-23, SC-28, SC-40, SI-3, SI-7. SC-23: Session Authenticity Protect the authenticity of communications sessions. SC-23 Protecting session authenticity addresses communications protection at the session level, not at the packet level. Such protection establishes grounds for confidence at both ends of communications sessions in the ongoing identities of other parties and the validity of transmitted information. Authenticity protection includes protecting against man-in-the-middle attacks, session hijacking, and the insertion of false information into sessions. AU-10, SC-8, SC-10, SC-11. SC-5: Denial-of-service Protection a. [Selection: Protect against; Limit] the effects of the following types of denial-of-service events: [Assignment: organization-defined types of denial-of-service events]; and b. Employ the following controls to achieve the denial-of-service objective: [Assignment: organization-defined controls by type of denial-of-service event]. SC-5 Denial-of-service events may occur due to a variety of internal and external causes, such as an attack by an adversary or a lack of planning to support organizational needs with respect to capacity and bandwidth. Such attacks can occur across a wide range of network protocols (e.g., IPv4, IPv6). A variety of technologies are available to limit or eliminate the origination and effects of denial-of-service events. For example, boundary protection devices can filter certain types of packets to protect system components on internal networks from being directly affected by or the source of denial-of-service attacks. Employing increased network capacity and bandwidth combined with service redundancy also reduces the susceptibility to denial-of-service events. CP-2, IR-4, SC-6, SC-7, SC-40. SC-6: Resource Availability Protect the availability of resources by allocating [Assignment: organization-defined resources] by [Selection (one or more): priority; quota; [Assignment: organization-defined controls]]. SC-6 Priority protection prevents lower-priority processes from delaying or interfering with the system that services higher-priority processes. Quotas prevent users or processes from obtaining more than predetermined amounts of resources. SC-5. SC-7: Boundary Protection a. Monitor and control communications at the external managed interfaces to the system and at key internal managed interfaces within the system; b. Implement subnetworks for publicly accessible system components that are [Selection: physically; logically] separated from internal organizational networks; and c. Connect to external networks or systems only through managed interfaces consisting of boundary protection devices arranged in accordance with an organizational security and privacy architecture. SC-7 Managed interfaces include gateways, routers, firewalls, guards, network-based malicious code analysis, virtualization systems, or encrypted tunnels implemented within a security architecture. Subnetworks that are physically or logically separated from internal networks are referred to as demilitarized zones or DMZs. Restricting or prohibiting interfaces within organizational systems includes restricting external web traffic to designated web servers within managed interfaces, prohibiting external traffic that appears to be spoofing internal addresses, and prohibiting internal traffic that appears to be spoofing external addresses. SP 800-189 provides additional information on source address validation techniques to prevent ingress and egress of traffic with spoofed addresses. Commercial telecommunications services are provided by network components and consolidated management systems shared by customers. These services may also include third party-provided access lines and other service elements. Such services may represent sources of increased risk despite contract security provisions. Boundary protection may be implemented as a common control for all or part of an organizational network such that the boundary to be protected is greater than a system-specific boundary (i.e., an authorization boundary). AC-4, AC-17, AC-18, AC-19, AC-20, AU-13, CA-3, CM-2, CM-4, CM-7, CM-10, CP-8, CP-10, IR-4, MA-4, PE-3, PL-8, PM-12, SA-8, SA-17, SC-5, SC-26, SC-32, SC-35, SC-43. SC-8: Transmission Confidentiality and Integrity Protect the [Selection (one or more): confidentiality; integrity] of transmitted information. SC-8 Protecting the confidentiality and integrity of transmitted information applies to internal and external networks as well as any system components that can transmit information, including servers, notebook computers, desktop computers, mobile devices, printers, copiers, scanners, facsimile machines, and radios. Unprotected communication paths are exposed to the possibility of interception and modification. Protecting the confidentiality and integrity of information can be accomplished by physical or logical means. Physical protection can be achieved by using protected distribution systems. A protected distribution system is a wireline or fiber-optics telecommunications system that includes terminals and adequate electromagnetic, acoustical, electrical, and physical controls to permit its use for the unencrypted transmission of classified information. Logical protection can be achieved by employing encryption techniques. Organizations that rely on commercial providers who offer transmission services as commodity services rather than as fully dedicated services may find it difficult to obtain the necessary assurances regarding the implementation of needed controls for transmission confidentiality and integrity. In such situations, organizations determine what types of confidentiality or integrity services are available in standard, commercial telecommunications service packages. If it is not feasible to obtain the necessary controls and assurances of control effectiveness through appropriate contracting vehicles, organizations can implement appropriate compensating controls. AC-17, AC-18, AU-10, IA-3, IA-8, IA-9, MA-4, PE-4, SA-4, SA-8, SC-7, SC-16, SC-20, SC-23, SC-28. SI-10: Information Input Validation Check the validity of the following information inputs: [Assignment: organization-defined information inputs to the system]. SI-10 Checking the valid syntax and semantics of system inputs—including character set, length, numerical range, and acceptable values—verifies that inputs match specified definitions for format and content. For example, if the organization specifies that numerical values between 1-100 are the only acceptable inputs for a field in a given application, inputs of 387, abc, or %K% are invalid inputs and are not accepted as input to the system. Valid inputs are likely to vary from field to field within a software application. Applications typically follow well-defined protocols that use structured messages (i.e., commands or queries) to communicate between software modules or system components. Structured messages can contain raw or unstructured data interspersed with metadata or control information. If software applications use attacker-supplied inputs to construct structured messages without properly encoding such messages, then the attacker could insert malicious commands or special characters that can cause the data to be interpreted as control information or metadata. Consequently, the module or component that receives the corrupted output will perform the wrong operations or otherwise interpret the data incorrectly. Prescreening inputs prior to passing them to interpreters prevents the content from being unintentionally interpreted as commands. Input validation ensures accurate and correct inputs and prevents attacks such as cross-site scripting and a variety of injection attacks. None. SI-11: Error Handling a. Generate error messages that provide information necessary for corrective actions without revealing information that could be exploited; and b. Reveal error messages only to [Assignment: organization-defined personnel or roles]. SI-11 Organizations consider the structure and content of error messages. The extent to which systems can handle error conditions is guided and informed by organizational policy and operational requirements. Exploitable information includes stack traces and implementation details; erroneous logon attempts with passwords mistakenly entered as the username; mission or business information that can be derived from, if not stated explicitly by, the information recorded; and personally identifiable information, such as account numbers, social security numbers, and credit card numbers. Error messages may also provide a covert channel for transmitting information. AU-2, AU-3, SC-31, SI-2, SI-15. SI-3: Malicious Code Protection a. Implement [Selection (one or more): signature based; non-signature based] malicious code protection mechanisms at system entry and exit points to detect and eradicate malicious code; b. Automatically update malicious code protection mechanisms as new releases are available in accordance with organizational configuration management policy and procedures; c. Configure malicious code protection mechanisms to: 1. Perform periodic scans of the system [Assignment: organization-defined frequency] and real-time scans of files from external sources at [Selection (one or more): endpoint; network entry and exit points] as the files are downloaded, opened, or executed in accordance with organizational policy; and 2. [Selection (one or more): block malicious code; quarantine malicious code; take [Assignment: organization-defined action]]; and send alert to [Assignment: organization-defined personnel or roles] in response to malicious code detection; and d. Address the receipt of false positives during malicious code detection and eradication and the resulting potential impact on the availability of the system. SI-3 System entry and exit points include firewalls, remote access servers, workstations, electronic mail servers, web servers, proxy servers, notebook computers, and mobile devices. Malicious code includes viruses, worms, Trojan horses, and spyware. Malicious code can also be encoded in various formats contained within compressed or hidden files or hidden in files using techniques such as steganography. Malicious code can be inserted into systems in a variety of ways, including by electronic mail, the world-wide web, and portable storage devices. Malicious code insertions occur through the exploitation of system vulnerabilities. A variety of technologies and methods exist to limit or eliminate the effects of malicious code. Malicious code protection mechanisms include both signature- and nonsignature-based technologies. Nonsignature-based detection mechanisms include artificial intelligence techniques that use heuristics to detect, analyze, and describe the characteristics or behavior of malicious code and to provide controls against such code for which signatures do not yet exist or for which existing signatures may not be effective. Malicious code for which active signatures do not yet exist or may be ineffective includes polymorphic malicious code (i.e., code that changes signatures when it replicates). Nonsignature-based mechanisms also include reputation-based technologies. In addition to the above technologies, pervasive configuration management, comprehensive software integrity controls, and anti-exploitation software may be effective in preventing the execution of unauthorized code. Malicious code may be present in commercial off-the-shelf software as well as custom-built software and could include logic bombs, backdoors, and other types of attacks that could affect organizational mission and business functions. In situations where malicious code cannot be detected by detection methods or technologies, organizations rely on other types of controls, including secure coding practices, configuration management and control, trusted procurement processes, and monitoring practices to ensure that software does not perform functions other than the functions intended. Organizations may determine that, in response to the detection of malicious code, different actions may be warranted. For example, organizations can define actions in response to malicious code detection during periodic scans, the detection of malicious downloads, or the detection of maliciousness when attempting to open or execute files. AC-4, AC-19, CM-3, CM-8, IR-4, MA-3, MA-4, PL-9, RA-5, SC-7, SC-23, SC-26, SC-28, SC-44, SI-2, SI-4, SI-7, SI-8, SI-15. SI-4: System Monitoring a. Monitor the system to detect: 1. Attacks and indicators of potential attacks in accordance with the following monitoring objectives: [Assignment: organization-defined monitoring objectives]; and 2. Unauthorized local, network, and remote connections; b. Identify unauthorized use of the system through the following techniques and methods: [Assignment: organization-defined techniques and methods]; c. Invoke internal monitoring capabilities or deploy monitoring devices: 1. Strategically within the system to collect organization-determined essential information; and 2. At ad hoc locations within the system to track specific types of transactions of interest to the organization; d. Analyze detected events and anomalies; e. Adjust the level of system monitoring activity when there is a change in risk to organizational operations and assets, individuals, other organizations, or the Nation; f. Obtain legal opinion regarding system monitoring activities; and g. Provide [Assignment: organization-defined system monitoring information] to [Assignment: organization-defined personnel or roles] [Selection (one or more): as needed; [Assignment: organization-defined frequency]]. SI-4 System monitoring includes external and internal monitoring. External monitoring includes the observation of events occurring at external interfaces to the system. Internal monitoring includes the observation of events occurring within the system. Organizations monitor systems by observing audit activities in real time or by observing other system aspects such as access patterns, characteristics of access, and other actions. The monitoring objectives guide and inform the determination of the events. System monitoring capabilities are achieved through a variety of tools and techniques, including intrusion detection and prevention systems, malicious code protection software, scanning tools, audit record monitoring software, and network monitoring software. Depending on the security architecture, the distribution and configuration of monitoring devices may impact throughput at key internal and external boundaries as well as at other locations across a network due to the introduction of network throughput latency. If throughput management is needed, such devices are strategically located and deployed as part of an established organization-wide security architecture. Strategic locations for monitoring devices include selected perimeter locations and near key servers and server farms that support critical applications. Monitoring devices are typically employed at the managed interfaces associated with controls SC-7 and AC-17. The information collected is a function of the organizational monitoring objectives and the capability of systems to support such objectives. Specific types of transactions of interest include Hypertext Transfer Protocol (HTTP) traffic that bypasses HTTP proxies. System monitoring is an integral part of organizational continuous monitoring and incident response programs, and output from system monitoring serves as input to those programs. System monitoring requirements, including the need for specific types of system monitoring, may be referenced in other controls (e.g., AC-2g, AC-2(7), AC-2(12)(a), AC-17(1), AU-13, AU-13(1), AU-13(2), CM-3f, CM-6d, MA-3a, MA-4a, SC-5(3)(b), SC-7a, SC-7(24)(b), SC-18b, SC-43b). Adjustments to levels of system monitoring are based on law enforcement information, intelligence information, or other sources of information. The legality of system monitoring activities is based on applicable laws, executive orders, directives, regulations, policies, standards, and guidelines. AC-2, AC-3, AC-4, AC-8, AC-17, AU-2, AU-6, AU-7, AU-9, AU-12, AU-13, AU-14, CA-7, CM-3, CM-6, CM-8, CM-11, IA-10, IR-4, MA-3, MA-4, PL-9, PM-12, RA-5, RA-10, SC-5, SC-7, SC-18, SC-26, SC-31, SC-35, SC-36, SC-37, SC-43, SI-3, SI-6, SI-7, SR-9, SR-10. SR-2: Supply Chain Risk Management Plan a. Develop a plan for managing supply chain risks associated with the research and development, design, manufacturing, acquisition, delivery, integration, operations and maintenance, and disposal of the following systems, system components or system services: [Assignment: organization-defined systems, system components, or system services]; b. Review and update the supply chain risk management plan [Assignment: organization-defined frequency] or as required, to address threat, organizational or environmental changes; and c. Protect the supply chain risk management plan from unauthorized disclosure and modification. SR-2 The dependence on products, systems, and services from external providers, as well as the nature of the relationships with those providers, present an increasing level of risk to an organization. Threat actions that may increase security or privacy risks include unauthorized production, the insertion or use of counterfeits, tampering, theft, insertion of malicious software and hardware, and poor manufacturing and development practices in the supply chain. Supply chain risks can be endemic or systemic within a system element or component, a system, an organization, a sector, or the Nation. Managing supply chain risk is a complex, multifaceted undertaking that requires a coordinated effort across an organization to build trust relationships and communicate with internal and external stakeholders. Supply chain risk management (SCRM) activities include identifying and assessing risks, determining appropriate risk response actions, developing SCRM plans to document response actions, and monitoring performance against plans. The SCRM plan (at the system-level) is implementation specific, providing policy implementation, requirements, constraints and implications. It can either be stand-alone, or incorporated into system security and privacy plans. The SCRM plan addresses managing, implementation, and monitoring of SCRM controls and the development/sustainment of systems across the SDLC to support mission and business functions. Because supply chains can differ significantly across and within organizations, SCRM plans are tailored to the individual program, organizational, and operational contexts. Tailored SCRM plans provide the basis for determining whether a technology, service, system component, or system is fit for purpose, and as such, the controls need to be tailored accordingly. Tailored SCRM plans help organizations focus their resources on the most critical mission and business functions based on mission and business requirements and their risk environment. Supply chain risk management plans include an expression of the supply chain risk tolerance for the organization, acceptable supply chain risk mitigation strategies or controls, a process for consistently evaluating and monitoring supply chain risk, approaches for implementing and communicating the plan, a description of and justification for supply chain risk mitigation measures taken, and associated roles and responsibilities. Finally, supply chain risk management plans address requirements for developing trustworthy, secure, privacy-protective, and resilient system components and systems, including the application of the security design principles implemented as part of life cycle-based systems security engineering processes (see SA-8). CA-2, CP-4, IR-4, MA-2, MA-6, PE-16, PL-2, PM-9, PM-30, RA-3, RA-7, SA-8, SI-4. SR-3: Supply Chain Controls and Processes a. Establish a process or processes to identify and address weaknesses or deficiencies in the supply chain elements and processes of [Assignment: organization-defined system or system component] in coordination with [Assignment: organization-defined supply chain personnel]; b. Employ the following controls to protect against supply chain risks to the system, system component, or system service and to limit the harm or consequences from supply chain-related events: [Assignment: organization-defined supply chain controls]; and c. Document the selected and implemented supply chain processes and controls in [Selection: security and privacy plans; supply chain risk management plan; [Assignment: organization-defined document]]. SR-3 Supply chain elements include organizations, entities, or tools employed for the research and development, design, manufacturing, acquisition, delivery, integration, operations and maintenance, and disposal of systems and system components. Supply chain processes include hardware, software, and firmware development processes; shipping and handling procedures; personnel security and physical security programs; configuration management tools, techniques, and measures to maintain provenance; or other programs, processes, or procedures associated with the development, acquisition, maintenance and disposal of systems and system components. Supply chain elements and processes may be provided by organizations, system integrators, or external providers. Weaknesses or deficiencies in supply chain elements or processes represent potential vulnerabilities that can be exploited by adversaries to cause harm to the organization and affect its ability to carry out its core missions or business functions. Supply chain personnel are individuals with roles and responsibilities in the supply chain. CA-2, MA-2, MA-6, PE-3, PE-16, PL-8, PM-30, SA-2, SA-3, SA-4, SA-5, SA-8, SA-9, SA-10, SA-15, SC-7, SC-29, SC-30, SC-38, SI-7, SR-6, SR-9, SR-11. STRIDE-001: Spoofing STRIDE-001 An attack where an entity illegitimately pretends to be another. This includes impersonating a user, process, or device to gain unauthorized access. STRIDE-002: Tampering STRIDE-002 Unauthorized modification of data, whether at rest or in transit. This can alter system behavior, compromise data integrity, or introduce malicious code. STRIDE-004: Information disclosure STRIDE-004 The unauthorized exposure of information to individuals or systems that should not have access to it. This includes data leaks, unintentional sharing, and improper access controls. STRIDE-005: Denial of service STRIDE-005 An attack that disrupts normal service operations, making a system or resource unavailable to its intended users by overwhelming or crashing it. STRIDE-006: Elevation of privilege STRIDE-006 Occurs when a user gains higher access rights or permissions than intended. Attackers exploit flaws to execute unauthorized actions with elevated privileges. STS-02: Identity governance and administration service Manages user identities, roles, and access rights across systems. STS-02 Proposed STS-03: Identity provider service Authenticates users and provides single sign-on to applications. STS-03 Proposed STS-04: Security testing service Analyzes application source code to detect security weaknesses. STS-04 Proposed STS-12: Vulnerability management service Identifies, prioritizes, and tracks vulnerabilities in systems. Checking on systems whether outdated software is run STS-12 Proposed STS-13: Security information and event management service Collects and analyzes security events for threat detection and compliance. STS-13 Proposed STS-17: Web application firewall service Protects web applications from attacks such as sql injection and cross-site scripting. STS-17 Proposed STS-21: Distributed denial of service protection service Protects against (distribute) denial of service attacks by filtering out requests should they lead to capacity issue. STS-21 Proposed STS-23: Secure service gateway (API gateway) Protects APIs against common attacks, and evaluations (coarse-grained) authorization policies STS-23 Proposed STS-26: Asset management service Removed as it is not a security service - we depend on it. STS-26 Removed STS-28: Secure configuration management service This includes baseline management, security posture management & compliance management STS-28 Proposed STS-40: Third party risk management service New based on list of Thijs STS-40 Proposed Server-based application Service Unauthorized changes or manipulation of data records Custom threat (no CAPEC meta) Web client REST HTTP / GraphQL / gRPC / websocket REST HTTP / GraphQL / gRPC / websocket External token REST HTTP / GraphQL / gRPC / websocket Internal token HTTPS External token This relationship has been converted from "assignment" to "association" REST HTTP / GraphQL / gRPC / websocket External token Data out This relationship has been converted from "assignment" to "association" This relationship has been converted from "assignment" to "association" REST HTTP / GraphQL / gRPC / websocket External token This relationship has been converted from "assignment" to "association" None JDBC / other HTTPS Cookie This relationship has been converted from "assignment" to "association" Data in Data in HTTPS Internal token domain A Data out Application Business CAPEC Threat Library (meta-attack patterns) STRIDE Threat Library Motivation NIST 800-53 Controls Relations Technology & Physical NORA zones Technology services Removed Views 2. Patterns API inbound security pattern repository Discussion Related Controls Original ID Abstraction Alternate Terms Likelihood Of Attack Typical Severity Related Attack Patterns Execution Flow Prerequisites homepage Skills Required Resources Required Indicators Consequences Mitigations Example Instances Related Weaknesses Taxonomy Mappings Notes Description licence Source Protocol Type Authentication Flow Communication channel Encryption at data layer Destination port Data Name attribution Pattern ID Version Also known as Contributor(s) Intent When to use When not to use Assumptions Typical challenges Variants, refinements and combinations contains Known uses Attribution and references Structure description Variations source model ID Status Control Identifier 1. API inbound security pattern [Threat Model] API inbound security pattern SP-030 0.1 Draft API inbound - ESA pattern Michael Boeynaems, Fabien Antiga, Roos Hubrechtsen This pattern secures an API that an organisation publishes to consumers and partners, and the inbound call that reaches it. It starts from the threats rather than the controls. Nine threats are named, each anchored to a STRIDE-LM category, and 32 NIST 800-53 base controls answer them. A control with no threat behind it does not belong in the pattern. The scope is the inbound path: the consumer, the zones the call crosses, the web application firewall, the API gateway, the token exchange and the service that answers. Payload signing and payload encryption sit outside it. ArchiMate draws the pattern twice. The threat model shows what can go wrong. The control realisation names the security service that delivers each control. An organisation publishes an API to consumers outside the back office. The call arrives over HTTPS and the caller already holds an access token. The pattern covers REST, GraphQL, gRPC and websocket calls from web clients, mobile apps, partners and server-based applications. It also fits an early design review: which controls are needed, and why. Outbound traffic belongs to a separate pattern. SOAP is out of scope. The services involved solve payload signing and payload encryption. The pattern stops at the inbound path, so it covers neither the API lifecycle nor the storage behind the service. A network zoning model is in place and enforced. The pattern puts its elements in three zones: external, DMZ and back office. The API consumer holds a valid access token before the first call reaches the web application firewall. How that token was issued is outside this pattern. An identity provider validates the external token and issues the internal one used behind the gateway. The token exchange takes most of the effort. The gateway validates an external token and obtains an internal one, and both depend on IA-05 and SC-23. Weaken either and CAPEC-21 Exploitation of Trusted Identifiers succeeds. Teams treat one of SI-10's three placements as enough, and the refinements Allowlisting, Blocklisting, Detailed validation and Data sanitization then exist only at the edge. Teams handle denial of service as a network problem. SC-05 and SC-06 do sit there, but AC-10 and AC-12 sit with the identity provider, and that second pair stops a flood built from valid sessions. CM-08 carries two threats, footprinting and supply chain compromise. An out-of-date list of published APIs loses both. The pattern records one variation, API IA Threat Model, covering identity and authentication in more detail. No others are known. - Single-page web application calling an API. The token lives in the browser, so session handling carries most of the risk. - Business-to-business API integration. The caller is a server, so IA-09 authenticates the calling service. - Open banking. The consumer is a third party, so AC-20 and the supply chain controls apply. Standards and catalogues used in the model: - NIST SP 800-53 Rev 5, for the control identifiers and titles. Base controls only. - MITRE CAPEC, meta attack patterns, for the threat names. - STRIDE-LM, for the threat categories. References provided with the CSC pattern: - https://securitypatterns.io/docs/06-api-services-security-pattern/ - https://owasp.org/www-project-api-security/ - OWASP Cheat Sheet Series, Network Segmentation. - OWASP Cheat Sheet Series, OAuth 2.0. Read the view from left to right. On the left are two network zones, one above the other. NORA-1: External holds the API consumer, with a web client, a mobile app and a server-based application inside it. NORA-4: Back Office holds the service and the data store. The call runs down from one to the other. The DMZ and the security services sit on the control view, not here. A single column beside the zones holds the nine threats. The controls follow, one box per NIST base control, with a narrow column beside them for the four refinements of SI-10: Allowlisting, Blocklisting, Detailed validation and Data sanitization. An arrowhead means the control mitigates the threat it points at, and every mitigation relationship carries one. A line running left from a threat to a component has no arrowhead, because that relationship says only that the threat applies there. Every threat also carries a STRIDE-LM category. It is not drawn; the panel shows it when you select the threat. 2. API inbound security pattern [Control Realization] The diagram reads top to bottom. • API consumer connects with valid Access token over HTTPS to the WAF that performs specific controls. • WAF forwards the request to the API GW whilst passing external access token. API GW executes then its set of controls. • API GW calls token service to SWAP token type • API GW finally send the call with internal token to the API component in scope that executes also specific controls 0.1 API inbound - ESA pattern This pattern secures an API that an organisation publishes to consumers and partners, and the inbound call that reaches it. It starts from the threats rather than the controls. Nine threats are named, each anchored to a STRIDE-LM category, and 32 NIST 800-53 base controls answer them. A control with no threat behind it does not belong in the pattern. The scope is the inbound path: the consumer, the zones the call crosses, the web application firewall, the API gateway, the token exchange and the service that answers. Payload signing and payload encryption sit outside it. ArchiMate draws the pattern twice. The threat model shows what can go wrong. The control realisation names the security service that delivers each control. Michael Boeynaems, Fabien Antiga, Roos Hubrechtsen API IA Threat Model API inbound security pattern SP-030 Draft An organisation publishes an API to consumers outside the back office. The call arrives over HTTPS and the caller already holds an access token. The pattern covers REST, GraphQL, gRPC and websocket calls from web clients, mobile apps, partners and server-based applications. It also fits an early design review: which controls are needed, and why. Outbound traffic belongs to a separate pattern. SOAP is out of scope. The services involved solve payload signing and payload encryption. The pattern stops at the inbound path, so it covers neither the API lifecycle nor the storage behind the service. A network zoning model is in place and enforced. The pattern puts its elements in three zones: external, DMZ and back office. The API consumer holds a valid access token before the first call reaches the web application firewall. How that token was issued is outside this pattern. An identity provider validates the external token and issues the internal one used behind the gateway. The token exchange takes most of the effort. The gateway validates an external token and obtains an internal one, and both depend on IA-05 and SC-23. Weaken either and CAPEC-21 Exploitation of Trusted Identifiers succeeds. Teams treat one of SI-10's three placements as enough, and the refinements Allowlisting, Blocklisting, Detailed validation and Data sanitization then exist only at the edge. Teams handle denial of service as a network problem. SC-05 and SC-06 do sit there, but AC-10 and AC-12 sit with the identity provider, and that second pair stops a flood built from valid sessions. CM-08 carries two threats, footprinting and supply chain compromise. An out-of-date list of published APIs loses both. The pattern records one variation, API IA Threat Model, covering identity and authentication in more detail. No others are known. - Single-page web application calling an API. The token lives in the browser, so session handling carries most of the risk. - Business-to-business API integration. The caller is a server, so IA-09 authenticates the calling service. - Open banking. The consumer is a third party, so AC-20 and the supply chain controls apply. Standards and catalogues used in the model: - NIST SP 800-53 Rev 5, for the control identifiers and titles. Base controls only. - MITRE CAPEC, meta attack patterns, for the threat names. - STRIDE-LM, for the threat categories. References provided with the CSC pattern: - https://securitypatterns.io/docs/06-api-services-security-pattern/ - https://owasp.org/www-project-api-security/ - OWASP Cheat Sheet Series, Network Segmentation. - OWASP Cheat Sheet Series, OAuth 2.0. The three network zones form a spine down the middle of the view, one above the other. NORA-1: External holds the API consumer and its three client types. NORA-2: DMZ holds STS-21 distributed denial of service protection, STS-17 web application firewall and STS-23 secure service gateway. NORA-4: Back Office holds the service, the data store and eight more security services. The controls sit left and right of that spine, each beside the service that realises it. A control appears once for each service that delivers it. SI-10 is drawn three times: at the web application firewall, at the gateway and at the service. The repetition shows where along the path the control applies.