Application-Centric Security Countermeasures

We provide an overview of existing countermeasures that focus on one or more threats, and address gaps and challenges in Appendix A.5 of document D4.3. This section aims to present the status of cybersecurity solutions connecting them to identified threats and gaps. We discuss classes of countermeasures, each describing the most relevant solutions to date.

• C5.1 – Security by default. It refers to the technologies which enable security best practices by default, requiring little to no manual intervention. They help in solving all those long-standing issues and threats which are widely known but still largely exploited. There are many security-by-default techniques that can be applied at different levels, including the following. At the low level, programming language compilers that add safety and security features (e.g., buffer overflow protection) to the compiled code are used in many modern programming languages (e.g., Java, Python), with built-in dynamic analysis tools (e.g., fuzzing in Go), [1] offering in some cases very strong guarantees (e.g., memory safety at compile time in the case of Rust) [2]. Moving up on the stack, modern web frameworks offer protections from common threats such as SQL Injection [3], XSS (Cross-Site Scripting). At a high level, orchestration platforms (e.g., Docker Swarm, Kubernetes) offer SDNs (Software Defined Networks) with many security features, including automatic encryption and mutual authentication (see C5.3) [4][5]. The key point that makes these solutions a step forward is that they require very little effort to set up their security and safety features. Some of them even aim to provide security features without modifying the application code. In fact, security by default is fundamental in a scenario where 65% of publicly disclosed cloud security incidents are the result of cloud customer misconfigurations [6].
  Threats: T5.1.1 – Security misconfiguration, T5.2.1 – Interception of information, T5.2.2 – Sensitive data exposure, T5.3.1 – Broken authentication and access control, T5.3.3 – Code execution and injection (unsecured APIs), T5.3.6 – Supply-chain security
  Gaps: G5.1 – Gaps on microservice-aware security, G5.2 – Gaps on authentication and authorization, G5.3 – Gaps on orchestration and composition, G5.4 – Gaps on safety and security by default, G5.5 – Gaps on the proper management of configurations, G5.6 – Gaps on supply-chain security, G5.7 – Gaps on skills
• C5.2 – Authentication and Authorization. It refers to the activities where the user who wants to access a resource is first identified (authentication) and then, eventually, authorized (authorization). Recent advances in threats paired with the long-standing issue of weak passwords call for new methods for authentication and authorization. On one side, MFA (Multi-Factor Authentication) is becoming the go-to technology to improve authentication. On the other side, advanced paradigms began to be used outside of research (e.g., attribute-based access control). If applied correctly, e.g., the two-men rule, they can partially mitigate threats such as malicious insiders. However, the complexity of such solutions is also increasing, and designers and implementors must make careful choices to avoid opening up for new threats. We note that in microservice and distributed systems authentication and authorization is performed directly from service to service, hence the concept of users may not be enough [7].
  Threats: T5.1.2 – Inadequate design, T5.2.2 – Sensitive data exposure, T5.3.1 – Broken authentication and access control, T5.5.1 – Malicious insider
  Gaps: G5.1 – Gaps on microservice-aware security, G5.2 – Gaps on authentication and authorization, G5.4 – Gaps on safety and security by default, G5.7 – Gaps on skills, G5.9 – Gaps on education, G5.10 – Gaps on sophisticated protection
• C5.3 – Orchestration Platforms. They refer to the very fundamental requirement for every system based on containers. Orchestration platforms such as Kubernetes enable automatic deployment, resource management, scaling, and programming patterns required to write the very minimum amount of code (serverless). Beyond that, they provide a set of ready-to-use building blocks that can help solve many use cases, either as built-in or as add-ons. Among them, comprehensive and monitoring solutions (e.g., OpenTelemetry [8]), layer-7 security solutions eventually the basis of C5.2 (e.g., Cilium [9]), container-native threat detection (e.g., Falco [10]). In short, orchestration platforms can greatly simplify many common tasks, some of them related to security. Nevertheless, as specified in deliverable D4.2, they may have vulnerabilities themselves and require mastering many concepts. This countermeasure is related to C5.1, i.e., such platforms should in any case be secure by default. Finally, they can be often paired with tools to automate configurations and deployments aimed at reducing human errors (e.g., IaC – Infrastructure as Code) [6][11].
  Threats: T5.1.1 – Security misconfiguration, T5.1.2 – Inadequate design, T5.2.1 – Interception of information, T5.2.2 – Sensitive data exposure, T5.3.1 – Broken authentication and access control, T5.3.2 – Denial of service, T5.3.3 – Code execution and injection (unsecured APIs), T5.3.4 – Insufficient logging and monitoring, T5.3.5 – Untrusted composition, T5.3.7 – Virtualization
  Gaps: G5.1 – Gaps on microservice-aware security, G5.2 – Gaps on authentication and authorization, G5.3 – Gaps on orchestration and composition, G5.4 – Gaps on safety and security by default, G5.5 – Gaps on the proper management of configurations, G5.7 – Gaps on skills, G5.10 – Gaps on sophisticated protection
• C5.4 – Sandboxing. It refers to the techniques isolating a (set of) processes, often aiming at reducing attack spreading and failures. In a nutshell, the principle is to make the running process unable to escape the sandbox for none but the allowed actions. The gold standard for sandboxing is containerization, a lightweight virtualization technology (i.e., Docker). Recently, another promising technology is WebAssembly, an assembly-like language born to speed up client-side Javascript. WebAssembly is rapidly gaining attention also for server-side execution, with WebAssembly runtimes offering built-in sandboxing [12]. Many compilers are adding WebAssembly as a target, and some providers are offering WebAssembly-based hosting platforms [13]. In short, it is becoming a revival of the old motto “write once, run anywhere”, but in a multi-language fashion. In fact, these kinds of sandboxing (i.e., containers and WebAssembly), favour also portability; but threat actors are already maliciously exploiting them for, e.g., obfuscation [14].
  Threats: T5.1.1– Security misconfiguration, T5.1.2 – Inadequate design, T5.3.3 – Code execution and injection (unsecured APIs), T5.3.7 – Virtualization
  Gaps: G5.1 – Gaps on microservice-aware security, G5.4 – Gaps on safety and security by default, G5.6 – Gaps on supply-chain security, G5.7 – Gaps on skills, G5.8 – Gaps on interoperability

---

Highlights on Identified Countermeasures

The above countermeasures consider two main directions: i) simplifying the security-related maintenance burden on developers and IT admins; ii) providing improved protection. The recent years have seen the trends of shifting security “to the left”, culminating in the definition of development methodologies such as DevSecOps. In short, they advocate for the early inclusion of security in the development process, making it one of the pillars guiding all the choices. In this context, solutions that are already secure or safe play a crucial role, reducing the efforts both of developers and system administrators. They greatly help in removing many long-standing issues still affecting the security landscape [15], allowing personnel to focus on sophisticated security aspects. In other words, existing countermeasures are forming the basis on which more sophisticated solutions should be built.

---

[1] The Go Blog. Fuzzing is Beta Ready. https://blog.golang.org/fuzz-beta

[2] Microsoft Security Response Center. Why Rust for safe systems programming. https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe-systems-programming/

[3] Spring Javadoc. Class NamedParameterJdbcTemplate. https://docs.spring.io/spring-framework/docs/5.3.0/javadoc-api/index.html?org/springframework/jdbc/core/namedparam/NamedParameterJdbcTemplate.html

[4] Docker. Use overlay networks. https://docs.docker.com/network/overlay/#encrypt-traffic-on-an-overlay-network

[5] Istio. Security. https://istio.io/latest/docs/concepts/security/

[6] Palo Alto Unit 42. Cloud Threat Report 1H 2021

[7] Istio. Security – Authentication. https://istio.io/latest/docs/concepts/security/#authentication

[8] OpenTelemetry. https://opentelemetry.io/

[9] Cilium. https://cilium.io/

[10] Falco. https://falco.org/

[11] Microsoft. What Is Infrastructure as Code? https://docs.microsoft.com/en-us/devops/deliver/what-is-infrastructure-as-code

[12] Wasmer. https://wasmer.io/

[13] Cloudflare Workers. Languages. https://developers.cloudflare.com/workers/platform/languages#wasm-supported

[14] M. Musch C. Wressnegger, M. Johns, K. Rieck. “New Kid on the Web: A Study on the Prevalence of WebAssembly in the Wild”. In Proc of DIMVA 2019. Gothenburg, Sweden

[15] OWASP Top Ten 2017. https://owasp.org/www-project-top-ten/2017/