Special | A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z | ALL
2 |
---|
2022 cyber threat trends | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Every year, major cybersecurity firms release their report on the trends of cyber threats/attacks they observe during that year. Some also release their forecast of cybersecurity trends for the next year. Examples of reports for 2022 are provided in the list of references. A summary of the trends observed in these reports is provided here, with additional commentary on how some of these attacks happened. Among the most impactful trends identified [Che22, Cro22b, Man22a, Spl22] are (in no particular order):
References
| ||||||||||||||||
A |
---|
Abstract interpretation | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
High-level overviewAbstract interpretation, first formalised by Cousot and Cousot in 1977 [CC77], executes a program on an abstract machine to determine the properties of interest [vJ11, p. 1255]. The level of detail in the abstract machine specification typically determines the accuracy of the results. At one end of the spectrum is an abstract machine that faithfully represents the concrete semantics of the language. Abstract interpretation on such a machine 👆 would correspond to a concrete execution on the real machine. Typical abstract interpretation analyses, however, do not require detailed semantics. A bit of theoryFundamentally, the correctness problem of a program is undecidable, so approximation is necessary [Cou01, Abstract]. The purpose of abstract interpretation is to formalise this idea 👆 of approximation; see Fig. 1. Formally, abstract interpretation is founded in the theory for approximating sets and set operations [Cou01, Sec. 2]. The semantics of a program can be defined as the solution to a fixpoint (short for fixed point) equation. Thus, an essential role of abstract interpretation is providing constructive and effective methods for fixpoint approximation and checking by abstraction. By observing computations at different levels of abstraction (trace semantics → relational semantics → denotational semantics → weakest precondition semantics → Hoare logics), fixpoints can be approximated. References
| ||||||||||
Address space layout randomisation (ASLR) | ||||
---|---|---|---|---|
Address space layout randomisation (ASLR) refers to the randomisation of the locations of the key components of an executable — stack, heap, libraries and memory-mapped files, executable code — in the address space; to mitigate remote code execution and other attacks targeting CWE-787 and CWE-125. Watch Dr. Yeongjin Jang’s lecture on ASLR: ASLR targets memory corruption vulnerabilities such as buffer overflows, which typically occur when data get written to memory that is smaller than the size of the data — a common programming error when using a memory-unsafe language like C. By introducing uncertainty into the locations of the shellcode (or any other attack code), ASLR hinders exploitations of memory corruption vulnerabilities. There are many ways ASLR can be done, and different operating systems do it differently. There are three dimensions to be considered [MGRR19]: When This is about when the entropy used for ASLR is generated (see Table 1):
What This is about what to randomise. In the extreme, if a single object (e.g., the executable) is not randomised, ASLR is considered to be broken. An “aggressive” form of ASLR is when the randomisation is applied to the logical elements contained in the memory objects: processor instructions, blocks of code, functions, and even the data structures of the application; see Table 1. In this case 👆, the compiler, linker and loader are required to play an active role. This form of ASLR is not known to be in use. How Table 1 lists the main strategies:
References
| ||||
Advanced persistent threat (APT) | ||||
---|---|---|---|---|
Advanced persistent threat (APT, see Definition 1) has been occupying the attention of many cybersecurity firms. Definition 1: Advanced persistent threat (APT) [NIS11, Appendix B]
An adversary that possesses sophisticated levels of expertise and significant resources which allow it to create opportunities to achieve its objectives using multiple attack vectors (e.g., cyber, physical, and deception). These objectives typically include establishing and extending footholds within the information technology infrastructure of the targeted organisations for purposes of exfiltrating information, undermining or impeding critical aspects of a mission, program, or organization; or positioning itself to carry out these objectives in the future. The advanced persistent threat: 1️⃣ pursues its objectives repeatedly over an extended period of time; 2️⃣ adapts to defenders’ efforts to resist it; and 3️⃣ is determined to maintain the level of interaction needed to execute its objectives. Since APT groups are characterised by sophistication, persistence and resourcefulness, they are challenging to counter. Lists of APT groups are being actively maintained, e.g., by MITRE and Mandiant. References
| ||||
Application security testing | ||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Application security testing can be static or dynamic. Static application security testing (SAST) is a specialisation of static (code/program) analysis. Watch an introduction to static code analysis on LinkedIn Learning: Static analysis from Developing Secure Software by Jungwoo Ryoo Exploring tools for static analysis from Developing Secure Software by Jungwoo Ryoo Definitions and history:
Challenges:
Tools:
Dynamic application security testing (DAST) is a specialisation of dynamic (code/program) analysis. Watch an introduction to dynamic code analysis on LinkedIn Learning: Dynamic analysis from Developing Secure Software by Jungwoo Ryoo Dynamic analysis tools from Developing Secure Software by Jungwoo Ryoo Definitions and history:
Challenges:
Tools: References
| ||||||||||||||||||||||||||||
Asymmetric-key cryptography | ||
---|---|---|
Authenticated encryption with associated data (AEAD) | |||
---|---|---|---|
See 👇 attachment (coming soon) or the latest source on Overleaf. | |||
B |
---|
Block ciphers and their modes of operation | |||
---|---|---|---|
See 👇 attachment or the latest source on Overleaf, for block ciphers and their modes of operation.
| |||
Bundle Protocol | ||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
The original purpose of the delay-tolerant networking (DTN) protocols was to provide space communications scenarios with network-layer functionality similar to that provided by IP-based networks on Earth. Since space communication scenarios cannot be supported by the terrestrial IP protocol suite, a new solution had to be developed. The CCSDS Bundle Protocol (BP), based on Bundle Protocol version 6 as defined in RFC 5050 [SB07] and RFC 6260 [Bur11], is meant to provide 1️⃣ basic network-layer functionality, and 2️⃣ storage capability to enable networking benefits even in the presence of delays, disconnections, and rate mismatches [IEH+19].
More concretely, the BP provides network-layer services to applications through these capabilities [CCS15, Secs. 1.1 and 2.1]:
When used in conjunction with the Bundle Security Protocol, as defined in RFC 6257 [FWSL11], the BP also provides:
The BP is such an important protocol several open-source implementations exist:
References
| ||||||||||||||||||||||||||||
C |
---|
CCSDS File Delivery Protocol | ||||||||
---|---|---|---|---|---|---|---|---|
The CCSDS File Delivery Protocol (CFDP) is standardised in
CFDP has existed for decades, and it is intended to enable packet delivery services in space (space-to-ground, ground-to-space, and space-to-space) environments [CCS20, Sec. 1.1]. CFDP defines 1️⃣ a protocol suitable for the transmission of files to and from spacecraft data storage, and 2️⃣ file management services to allow control over the storage medium [CCS20, Sec. 2.1]. CFDP assumes a virtual filestore and associated services that an implementation must map to the capabilities of the actual underlying filestore used [CCS20, Sec. 1.1]. File transfers can be either unrealiable (class 1) or reliable (class 2): Class 1 [CCS20, Sec. 7.2] All file segments are transferred without the possibility of retransmission. End of file (EOF) is not acknowledged by the receiver. When the flag Closure Requested is set, the receiver is required to send a Finished PDU upon receiving all file segments (or when the request is cancelled), but the sender does not need to acknowledge the Finished PDU. The Closure Requested flag is useful when the underlying communication protocol is reliable. Class 2 [CCS20, Sec. 7.3] The receiver is required to acknowledge the EOF PDU and the sender has to acknowledge the Finished PDU. Sending a PDU that requires acknowledgment triggers a timer. When the timer expires and if the acknowledgment has not been received, the relevant file segment PDU is resent. This repeats until the ACK Timer Expiration Counter [CCS21b, Sec. 4.4] reaches a predefined maximum value. Finally, if the counter has reached its maximum value and the acknowledgment has still not been received, a fault condition is triggered which may cause the transfer to be abandoned, canceled or suspended. The receiver can also indicate missing metadata or data by sending NAK PDUs. Fig. 2 shows a sample class-2 Copy File transaction between two entities. Fig. 3 summarises 1️⃣the operation primitives and PDUs in CFDP, as well as 2️⃣ the relationships of these primitives and PDUs to the operational process from initiation through termination. Watch an introduction to the CFDP on YouTube: There are several open-source implementations of CFDP, e.g.,
References
| ||||||||