Core Security Principles and Concepts

# Chapter 3: Core Security Principles and Concepts

Prior to diving further into threats and protection, it's essential to establish the fundamental principles that underlie application security. These kinds of core concepts are usually the compass through which security professionals navigate decisions and trade-offs. They help remedy why certain controls are necessary in addition to what goals all of us are trying to achieve. Several foundational models and principles slowly move the design and evaluation of safe systems, the almost all famous being the particular CIA triad and even associated security concepts.

## The CIA Triad – Discretion, Integrity, Availability

In the middle of information protection (including application security) are three main goals:

1. **Confidentiality** – Preventing unapproved access to information. Within simple terms, preserving secrets secret. Simply those who are authorized (have typically the right credentials or even permissions) should end up being able to watch or use very sensitive data. According to NIST, confidentiality indicates "preserving authorized restrictions on access and even disclosure, including methods for protecting personalized privacy and exclusive information"​
PTGMEDIA. PEARSONCMG. COM
. Breaches associated with confidentiality include trends like data leakages, password disclosure, or even an attacker looking at someone else's e-mails. A real-world illustration is an SQL injection attack of which dumps all user records from a database: data of which should have been confidential is subjected to typically the attacker. The other associated with confidentiality is disclosure​
PTGMEDIA. PEARSONCMG. COM
– when details is showed those not authorized to be able to see it.

a couple of. **Integrity** – Protecting data and techniques from unauthorized adjustment. Integrity means of which information remains precise and trustworthy, in addition to that system capabilities are not interfered with. For instance, if the banking application displays your consideration balance, integrity steps ensure that a great attacker hasn't illicitly altered that equilibrium either in transit or in typically the database. Integrity can be compromised simply by attacks like tampering (e. g., changing values in a LINK to access an individual else's data) or perhaps by faulty program code that corrupts info. A classic mechanism to make certain integrity is definitely the utilization of cryptographic hashes or autographs – in case a data file or message is altered, its personal will no longer verify. The opposite of integrity is definitely often termed modification – data becoming modified or corrupted without authorization​
PTGMEDIA. PEARSONCMG. COM
.

3 or more. **Availability** – Making sure systems and data are accessible as needed. Even if files is kept magic formula and unmodified, it's of little make use of in the event the application is down or unreachable. Availability means that will authorized users can easily reliably access the application and its functions in some sort of timely manner. Dangers to availability consist of DoS (Denial regarding Service) attacks, exactly where attackers flood a new server with site visitors or exploit some sort of vulnerability to accident the program, making this unavailable to legit users. Hardware disappointments, network outages, or even design issues that can't handle peak loads are furthermore availability risks. Typically the opposite of accessibility is often identified as destruction or denial – data or even services are ruined or withheld​
PTGMEDIA. PEARSONCMG. COM
. Typically the Morris Worm's impact in 1988 had been a stark reminder of the need for availability: it didn't steal or transform data, but by making systems crash or even slow (denying service), it caused main damage​
CCOE. DSCI. IN
.

These three – confidentiality, ethics, and availability – are sometimes called the "CIA triad" and are considered the three pillars associated with security. Depending about the context, the application might prioritize one over the others (for illustration, a public media website primarily cares that it's offered as well as content ethics is maintained, discretion is much less of a good issue since the articles is public; alternatively, a messaging software might put confidentiality at the top rated of its list). But a protected application ideally ought to enforce all three to an appropriate level. Many security controls can be realized as addressing one particular or more of those pillars: encryption aids confidentiality (by rushing data so just authorized can read it), checksums and audit logs help integrity, and redundancy or failover devices support availability.

## The DAD Triad (Opposites of CIA)

Sometimes it's beneficial to remember the flip side associated with the CIA triad, often called DADDY:

- **Disclosure** – Unauthorized access to be able to information (breach associated with confidentiality).
- **Alteration** – Unauthorized change info (breach associated with integrity).
- **Destruction/Denial** – Unauthorized damage of information or denial of service (breach of availability).

Safety efforts aim in order to prevent DAD results and uphold CIA. A single harm can involve numerous of these features. One example is, a ransomware attack might both disclose data (if the attacker steals a copy) in addition to deny availability (by encrypting the victim's copy, locking all of them out). A web exploit might alter data in a databases and thereby breach integrity, and so forth.

## Authentication, Authorization, plus Accountability (AAA)

Inside securing applications, especially multi-user systems, we all rely on added fundamental concepts often referred to as AAA:

1. **Authentication** – Verifying the particular identity of the user or program. When you log throughout with an account information (or more safely with multi-factor authentication), the system is definitely authenticating you – making sure you are usually who you promise to be. Authentication answers the issue: That are you? Frequent methods include account details, biometric scans, cryptographic keys, or bridal party. A core basic principle is the fact authentication ought to be sufficiently strong to be able to thwart impersonation. Fragile authentication (like very easily guessable passwords or even no authentication high should be) is actually a frequent cause associated with breaches.

2. **Authorization** – Once personality is made, authorization controls what actions or data the authenticated entity is authorized to access. This answers: What are a person allowed to do? For example, right after you log in, an online banking program will authorize one to see your own account details yet not someone else's. Authorization typically involves defining roles or perhaps permissions. A common susceptability, Broken Access Handle, occurs when these checks fail – say, an opponent finds that by simply changing a list IDENTITY in an URL they can watch another user's data because the application isn't properly verifying their particular authorization. In simple fact, Broken Access Handle was recognized as the particular number one web application risk in the 2021 OWASP Top 10, present in 94% of apps tested​
IMPERVA. COM
, illustrating how predominanent and important appropriate authorization is.

several. ** cyber criminal ** (and Auditing) – This refers to the ability to trace actions in typically the system for the liable entity, which often signifies having proper signing and audit hiking trails. If something goes wrong or dubious activity is discovered, we need to be able to know who do what. Accountability will be achieved through signing of user actions, and by possessing tamper-evident records. It works hand-in-hand with authentication (you can just hold someone accountable once you learn which bank account was performing a great action) and using integrity (logs on their own must be guarded from alteration). Throughout application security, setting up good logging and even monitoring is essential for both detecting incidents and undertaking forensic analysis following an incident. As we'll discuss inside of a later part, insufficient logging and monitoring enables removes to go unknown – OWASP shows this as an additional top 10 issue, remembering that without appropriate logs, organizations may well fail to notice an attack right up until it's far also late​
IMPERVA. APRESENTANDO
​
IMPERVA. APRESENTANDO
.

Sometimes you'll see an expanded acronym like IAAA (Identification, Authentication, Authorization, Accountability) which just breaks out identification (the claim of identification, e. g. entering username, before real authentication via password) as an individual step. But the core ideas continue to be a similar. A protected application typically enforces strong authentication, stringent authorization checks with regard to every request, in addition to maintains logs with regard to accountability.

## Rule of Least Freedom

One of the particular most important design and style principles in protection is to offer each user or perhaps component the minimum privileges necessary to perform its operate, with no more. This particular is called the rule of least opportunity. In practice, it indicates if an application has multiple functions (say admin versus regular user), the particular regular user balances should have not any capability to perform admin-only actions. If the web application demands to access a database, the data source account it uses must have permissions just for the precise furniture and operations necessary – one example is, in case the app in no way needs to remove data, the DB account shouldn't still have the REMOVE privilege. By limiting privileges, even if a great attacker compromises a good user account or a component, the damage is contained.

A stark example of not really following least opportunity was the Funds One breach of 2019: a misconfigured cloud permission allowed a compromised element (a web software firewall) to get all data from an S3 storage bucket, whereas in case that component had been limited to only a few data, the particular breach impact would have been a lot smaller​
KREBSONSECURITY. POSSUINDO
​
KREBSONSECURITY. APRESENTANDO
. Least privilege furthermore applies at the computer code level: when a module or microservice doesn't need certain access, it shouldn't have got it. Modern box orchestration and cloud IAM systems ensure it is easier to employ granular privileges, nevertheless it requires thoughtful design.

## Protection in Depth

This kind of principle suggests that will security should always be implemented in overlapping layers, in order that when one layer fails, others still provide protection. Put simply, don't rely on virtually any single security manage; assume it could be bypassed, and have additional mitigations in place. Regarding an application, protection in depth may well mean: you validate inputs on typically the client side for usability, but you also validate them on the server side (in case a great attacker bypasses your customer check). You safeguarded the database right behind an internal fire wall, but you also write code that checks user permissions prior to queries (assuming the attacker might break the rules of the network). In case using encryption, you might encrypt hypersensitive data within the data source, but also put in force access controls in the application layer in addition to monitor for strange query patterns. Defense in depth is definitely like the sheets of an onion – an opponent who gets via one layer ought to immediately face another. This approach counter tops the reality that no single defense is certain.

For example, imagine an application is dependent on a net application firewall (WAF) to block SQL injection attempts. Security in depth would claim the application form should nonetheless use safe code practices (like parameterized queries) to sanitize inputs, in circumstance the WAF yearns for a novel attack. A real situation highlighting this was basically the situation of specific web shells or even injection attacks that were not known by security filtration systems – the inner application controls next served as the particular final backstop.

## Secure by Style and Secure simply by Default

These connected principles emphasize making security an important consideration from the particular start of design and style, and choosing safe defaults. "Secure by design" means you want the system architecture with security inside mind – regarding instance, segregating hypersensitive components, using proven frameworks, and considering how each design decision could bring in risk. "Secure simply by default" means when the system is implemented, it may default to be able to the best adjustments, requiring deliberate actions to make it less secure (rather compared to the other way around).

An instance is default bank account policy: a safely designed application may possibly ship without having default admin password (forcing the installer to set a strong one) – as opposed to having a well-known default pass word that users may well forget to modify. Historically, many software packages were not secure by default; they'd install with wide open permissions or sample databases or debug modes active, if an admin opted to not lock them lower, it left cracks for attackers. Over time, vendors learned to be able to invert this: at this point, databases and operating systems often come with secure configurations out and about of the box (e. g., remote access disabled, sample users removed), and even it's up to the admin to loosen if definitely needed.

For designers, secure defaults suggest choosing safe collection functions by standard (e. g., arrears to parameterized questions, default to output encoding for internet templates, etc. ). It also means fail safe – if a part fails, it need to fail in the safe closed state instead than an inferior open state. For instance, if an authentication service times out there, a secure-by-default tackle would deny access (fail closed) somewhat than allow this.

## Privacy by Design

Idea, strongly related to safety measures by design, has gained prominence especially with laws like GDPR. It means that applications should always be designed not just in become secure, but to regard users' privacy by the ground upwards. Used, this may possibly involve data minimization (collecting only just what is necessary), transparency (users know what data is collected), and giving consumers control over their data. While privacy is a distinct site, it overlaps intensely with security: you can't have privacy if you can't secure the individual data you're dependable for. A lot of the worst data breaches (like those at credit rating bureaus, health insurance companies, etc. ) will be devastating not only due to security disappointment but because that they violate the privacy of an incredible number of people. Thus, modern program security often functions hand in hands with privacy concerns.

## Threat Modeling

A vital practice throughout secure design will be threat modeling – thinking like an attacker to foresee what could fail. During threat modeling, architects and designers systematically go coming from the design of an application to determine potential threats plus vulnerabilities. They request questions like: What are we building? What can proceed wrong? And what will we all do about it? One particular well-known methodology for threat modeling is usually STRIDE, developed from Microsoft, which holds for six kinds of threats: Spoofing identity, Tampering with information, Repudiation (deniability regarding actions), Information disclosure, Denial of assistance, and Elevation regarding privilege.

By strolling through each element of a system in addition to considering STRIDE hazards, teams can find out dangers that may not be obvious at first glance. For example, consider a simple online salaries application. Threat recreating might reveal that will: an attacker may spoof an employee's identity by questioning the session token (so we need to have strong randomness), could tamper with income values via a vulnerable parameter (so we need type validation and server-side checks), could conduct actions and later deny them (so we want good taxation logs to avoid repudiation), could make use of an information disclosure bug in a good error message to be able to glean sensitive information (so we have to have user-friendly but hazy errors), might attempt denial of service by submitting a huge file or heavy query (so we need level limiting and source quotas), or consider to elevate opportunity by accessing administrative functionality (so we all need robust access control checks). By way of this process, protection requirements and countermeasures become much better.

Threat modeling will be ideally done early on in development (during the style phase) so that security is usually built in from the beginning, aligning with typically the "secure by design" philosophy. It's the evolving practice – modern threat which may also consider abuse cases (how may the system always be misused beyond typically the intended threat model) and involve adversarial thinking exercises. We'll see its relevance again when discussing specific vulnerabilities in addition to how developers will foresee and prevent them.

## Chance Management

Its not all safety issue is every bit as critical, and assets are always small. So another strategy that permeates application security is risikomanagement. This involves examining the probability of a danger and the impact had been it to arise.  https://docs.shiftleft.io/ngsast/dashboard/dashboard-overview  is normally informally considered as a function of these a couple of: a vulnerability that's easy to exploit in addition to would cause extreme damage is high risk; one that's theoretical or might have minimal influence might be lower risk. Organizations frequently perform risk tests to prioritize their security efforts. Intended for example, an on the web retailer might decide that the risk of credit card robbery (through SQL shot or XSS resulting in session hijacking) is extremely high, and thus invest heavily in preventing those, although the risk of someone creating minor defacement on a less-used site might be approved or handled with lower priority.

Frameworks like NIST's or even ISO 27001's risikomanagement guidelines help inside systematically evaluating plus treating risks – whether by minify them, accepting these people, transferring them (insurance), or avoiding them by changing business practices.

One touchable response to risk supervision in application safety is the design of a danger matrix or danger register where potential threats are outlined along with their severity. This specific helps drive decisions like which bugs to fix first or where to allocate more screening effort. It's also reflected in repair management: if the new vulnerability is usually announced, teams is going to assess the chance to their software – is this exposed to that will vulnerability, how serious is it – to make the decision how urgently to utilize the patch or workaround.

## Security vs. Functionality vs. Cost

A new discussion of concepts wouldn't be complete without acknowledging the particular real-world balancing act. Security measures could introduce friction or cost. Strong authentication might mean even more steps for an user (like 2FA codes); encryption might decrease down performance slightly; extensive logging might raise storage fees. A principle to adhere to is to seek stability and proportionality – security should be commensurate with the particular value of what's being protected. Excessively burdensome security that will frustrates users may be counterproductive (users will dsicover unsafe workarounds, intended for instance). The skill of application safety is finding options that mitigate hazards while preserving some sort of good user knowledge and reasonable cost. Fortunately, with modern techniques, many protection measures can be made quite soft – for example of this, single sign-on solutions can improve the two security (fewer passwords) and usability, and even efficient cryptographic your local library make encryption hardly noticeable regarding efficiency.

In summary, these types of fundamental principles – CIA, AAA, very least privilege, defense thorough, secure by design/default, privacy considerations, menace modeling, and risikomanagement – form typically the mental framework for any security-conscious specialist. They will look repeatedly throughout information as we analyze specific technologies and even scenarios. Whenever you are unsure regarding a security decision, coming back to be able to these basics (e. g., "Am We protecting confidentiality? Are we validating integrity? Are we minimizing privileges? Can we have got multiple layers associated with defense? ") could guide you to some more secure outcome.

With  review suggestions  in mind, we can right now explore the exact threats and vulnerabilities that will plague applications, in addition to how to protect against them.