This page has general security concepts

Key Points

1. The Internet platform for public and private networks is based on several common security concepts
2. Internet security concepts can be applied at every layer in the network architecture ( see OSI network layer concepts )
3. For any proposed solution, a simple threat assessment can identify useful security solutions to lower risks
4. TCP is the primarily network protocol and supports multiple application protocols ( https, ftps, ucp etc )
5. Each application protocol can have network traffic secured using an encryption service ( eg http can be secured and run as https etc )
6. PKI ( public key infrastructure ) is a common solution to generating public and private keys to secure traffic, digitally sign documents etc
7. Newer technologies ( blockchain, AI, IoT etc ) all have dependencies on common security frameworks and solutions
8. In most environments, users and organizations need to be properly identified, often with digital identities to meet regulations ( AML, KYC etc )
9. Authentication - users, organizations authenticate to a service to validate their identity ( MFA etc )
10. Authorization - services normally validate an authenticated user is entitled to perform specific actions , access specific data ( rbac )
11. Entitlements - users are often assigned to roles that have specific entitlements ( authorizations ) for better management
12. Tokens - after a user logs in to a service,  authentication and authorization information is often stored in a user token for later access validation
13. Security services exist for encryption, single sign on, CORS, etc that make working securely easier in network environments
14. Data compression for performance in network and cloud environments ( faster io, lower storage costs etc )
15. Data encryption to preserve privacy
16. Homomorphic encryption - allows data privacy while sharing encrypted data that can be used to generate the same results from operations as the unencrypted data
17. Tokens generated for session access ( or ? ) after authentication

References

View a sender URL safely in an email in Microsoft Outlook

https://answers.microsoft.com/en-us/outlook_com/forum/all/how-can-i-look-inside-at-email-headers-without/4ee2a12d-6262-4480-8424-c19525ddfc31

With Outlook's default security settings, it is safe to open any email in the Reading Pane without fear of getting infected by any attachment, script or revealing that you opened the email to the original sender.

Anyway, to see the email header without opening the message, you can add the Message Options button to your Quick Access Toolbar; http://www.msoutlook.info/question/450

To view the original message source in the header as well, see; http://www.msoutlook.info/question/701

view a message header detail in Outlook

https://www.msoutlook.info/question/701

Key Concepts

there are many ways to provide security, confidentiality and privacy  at a session and service level - zero-trust models, certificates, mfa, sharded keys, rbac, data encryption, signed transactions, access monitoring etc. Most techniques will come under a common model for security - TEAR - track the issue, escalate the issue, audit the issue and remediate the issue. Enterprise Blockchain is one of the ways we can ensure data authenticity

Check Web Site Safety in Browsers

https://www.avg.com/en/signal/website-safety#:~:text=To%20find%20out%20if%20a,to%20use%20Google's%20URL%20scanner.

Check browser controls and settings for privacy and security

Use free anti-virus software for a phone or laptop

check the domain name on whois before accessing a site

Email Security and Phishing Attacks

Email Phishing Prevention articles

https://www.phishing.org/10-ways-to-avoid-phishing-scams

https://www.forbes.com/sites/forbestechcouncil/2019/06/21/top-five-best-practices-for-preventing-phishing-attacks/?sh=78508b632770

https://cofense.com/knowledge-center/anti-phishing-best-practices/

https://cofense.com/solutions/topic/anti-phishing/

https://cofense.com/knowledge-center/how-to-spot-phishing/

Manage phishing attempts in your email client

good email clients ( eg Gmail, Yahoo etc ) provide tools to help manage phishing attacks from bad actors

Action 1 - Verify sender URL

Action 2 - View raw message without "opening email"

Action 3 - Fully block sender and quarantine or delete email

Action 4 - Report the email to your Enterprise Mail team

Encryption Concepts 

https://www.techtarget.com/searchsecurity/definition/encryption#:~:text=A%20key%20chain%20is%20a,whenever%20neighboring%20routers%20exchange%20information.&text=Key%20chains%20allow%20a%20rotating,the%20likelihood%20of%20a%20compromise.

encryption-techtarget.pdf

Cipher Suites Overview

https://www.jscape.com/blog/cipher-suites

Basic Elements of a SSL/TLS Cipher Suite

The definition of a cipher suite is basically a complete set of methods (technically known as algorithms) needed to secure a network connection through SSL (Secure Sockets Layer) / TLS (Transport Layer Security). The name of each set is representative of the specific algorithms comprising it.

We'll show you how these names look like in a short while. In the meantime, let's talk about the algorithms that make up a SSL/TSL cipher suite. The algorithms that make up a typical cipher suite are the following:

• key exchange algorithm - dictates the manner by which symmetric keys will be exchanged;
• authentication algorithm - dictates how server authentication and (if needed) client authentication will be carried out. 
• bulk encryption algorithm - dictates which symmetric key algorithm will be used to encrypt the actual data; and 
• Message Authentication Code (MAC) algorithm - dictates the method the connection will use to carry out data integrity checks.

To be clear, one cipher suite typically consists of one (1) key exchange, 1 authentication, 1 bulk encryption, and 1 MAC algorithm. If you're not familiar with what these algorithms do, I suggest you open those links above in a new browser tabs and read them later.

Some key exchange algorithms: RSA, DH, ECDH, ECDHE;

Some authentication algorithms: RSA, DSA, ECDSA;

Some bulk encryption algorithms: AES, 3DES, CAMELLIA;

Some MAC algorithms: SHA, MD5

Here's an example of a typical cipher suite:

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384

Let's break that down.

• TLS simply indicates the protocol;
• ECDHE signifies the key exchange algorithm;
• ECDSA signifies the authentication algorithm;
• AES_256_CBC indicates the bulk encryption algorithm; and
• SHA384 indicates the MAC algorithm.

AES_256_CBC means that this cipher suite specifically uses 256-bit AES operating in CBC (cipher block chaining) mode.

Similarly, SHA384 means the cipher suite is employing a specific version of the Secure Hash Algorithm (SHA).

Sometimes, the protocol is simply omitted. Here's an example:

DHE_RSA_AES256_SHA

Again, breaking that down, we have:

• DHE - the key exchange algorithm;
• RSA - the authentication algorithm;
• AES256 - the bulk encryption algorithm; and
• SHA - the MAC algorithm

Sometimes, algorithms are implied. For example, in the cipher suite RSA_AES256_SHA, the authorization algorithm (RSA) is implied. 

Would you like to know what ciphers suites are supported by your browser? Head on to

https://cc.dcsec.uni-hannover.de/

or

https://www.ssllabs.com/ssltest/viewMyClient.html

for a quick practicum of what you've learned so far. The second site will even highlight which cipher suites are considered weak, i.e., have known vulnerabilities that can be exploited using existing tools and computing power.

As you can see, your browser supports a rather large selection of cipher suites. The server it's connecting to would normally have it's own selection as well. 

Here's a screenshot showing some of the cipher suites supported by JSCAPE MFT Server, a managed file transfer server that supports FTPS, HTTPS, WebDAVS, and other secure file transfer protocols:

Where SSL/TSL cipher suites are used

Cipher suites are used in network connections secured by SSL/TLS. That means, network protocols like HTTPS, FTPS, WebDAVS, AS2, POP3, IMAP, and SMTP, all use cipher suites. 

Before a client application and a server can exchange data over a SSL/TLS connection, these two parties need to agree first on a common set of algorithms to secure the connection. Yes, they're the algorithms we were talking about earlier. If the two parties fail to reach an agreement, then a connection won't be established.

The negotiation process takes place during what is commonly known as the SSL handshake. In the SSL handshake, the client begins by informing the server what cipher suites it supports. The cipher suites are usually arranged in order of security. The most secure cipher suite naturally becomes the first choice.

The server then compares those cipher suites with the cipher suites that are enabled on its side. As soon as it finds a match, it then informs the client, and the chosen cipher suite's algorithms are called into play.

Choosing cipher suites 

Your choice of cipher suites can spell the difference between having a secure connection and one that can be exploited. In order to avoid certain attacks, you will have to disable some cipher suites.

For example, in order to avoid the POODLE (Padding Oracle On Downgraded Legacy Encryption) attack, you will want to disable all cipher suites that use SSLv3. Or, if you want to prevent attackers from compromising your connection through the Logjam vulnerability, you will want to disable cipher suites that employ the Diffie-Hellman key exchange. 

Recommended read: SSL vs TLS - Know The Difference

The downside of disabling cipher suites is that it can cause compatibility issues. More specifically, it can prevent certain clients and servers from having matching cipher suites and establishing a connection. Since popular browsers like Chrome, Firefox, Safari, and Internet Explorer usually update their list of cipher suites after a vulnerability is discovered, it's always best to advise users to install the latest browser patches.

That way, you'll be able to reduce your users' likelihood of encountering compatibility issues when, say, you disable weak cipher suites on the server side.  

Data encryption

Encryption is the process of encoding information in such a way that eavesdroppers could not read the information unless they had a special key to decrypt it. Encryption is used everywhere, from banking transactions to your personal computer's hard drive.

Nonce to guarantee uniqueness typically on a hash value

http://tyleregeto.com/article/a-guide-to-nonce

Despite the abbreviation’s meaning, a nonce is any value that can be uniquely identified and tracked as having been used. We also want to verify that they came from us in the first place, that it was generated relatively recently, and that it was intended for the task the user is using it for.

The basic lifetime of a nonce is this:

1. A user requests a page that can trigger actions, eg: create or deleting content.
2. The requested page generates a nonce value and makes it part of the action, eg: a GET or POST parameter.
3. The user requests the action, the handler uses the nonce to validate the request.
4. On a successful nonce validation, the action is executed and the nonce is flagged as having been used.

In the rest of the article we will walk through these stages in the form of example code.

https://en.wikipedia.org/wiki/Cryptographic_nonce

Use of nonces for authentication scenarios between clients and servers to ensure unique requests - 

For instance, nonces are used in HTTP digest access authentication to calculate an MD5 digest of the password. The nonces are different each time the 401 authentication challenge response code is presented, thus making replay attacks virtually impossible. The scenario of ordering products over the Internet can provide an example of the usefulness of nonces in replay attacks. An attacker could take the encrypted information and—without needing to decrypt—could continue to send a particular order to the supplier, thereby ordering products over and over again under the same name and purchase information. The nonce is used to give 'originality' to a given message so that if the company receives any other orders from the same person with the same nonce, it will discard those as invalid orders.

A nonce may be used to ensure security for a stream cipher. Where the same key is used for more than one message and then a different nonce is used to ensure that the keystream is different for different messages encrypted with that key; often the message number is used.

Secret nonce values are used by the Lamport signature scheme as a signer-side secret which can be selectively revealed for comparison to public hashes for signature creation and verification.

https://searchsecurity.techtarget.com/definition/nonce

Typically, a nonce is some value that varies with time, in order to verify that specific values are not reused. A nonce can be a timestamp, a visit counter on a Web page or a special marker intended to limit or prevent the unauthorized replay or reproduction of a file.

creating a nonce

A nonce can be categorized based on how it is generated, either randomly or sequentially. A random nonce is produced by stringing arbitrary numbers together while a sequential nonce is produced incrementally. Using the sequential nonce method guarantees that values are not repeated, cannot be replayed and do not take up unnecessary space. However, using the random nonce method safeguards against attackers that collect multiple keys within the system. Ideally, a nonce will have a random and a sequential portion.

use cases for nonce

• authentication - using a nonce prevents a replay attack on authentication
  Generally, the server sends a nonce to the client, the client combines that nonce with the password and runs that through a hashing algorithm. Then the client sends the result to the server, who runs the same algorithm with the same nonce on the password it has stored and compares the results.
• hash - use nonce values to vary input to a cryptographic hash function.
• Initialization- An initialization vector (IV) is a nonce used for data encryption. The IV, used only once in any session, prevents a repetition of sequences in encrypted text
• Electronic signatures- Secret nonce values are sometimes used by e-signature tools to create, compare and verify signatures.
• cryptocurrency - In certain cryptocurrencies, a nonce is used to create a cryptographic hash that connects to a blockchain 
• Asymmetric cryptography- In specific instances of public key cryptography, like in the SSL/TLS handshake, two unique nonce values are exchanged. One value is provided by the client while the other is provided by the server, protecting each connection from attacks or interventions.

https://searchsecurity.techtarget.com/tip/The-ABCs-of-ciphertext-exploits-and-other-cryptography-attacks

Nonces, hashes, salts 

https://forum.openzeppelin.com/t/keys-nonces-and-salts/1324

Nonce use case

A nonce is a number that is unique in a particular cryptographic context (or a number that is used once). Since it doesn’t need to be unpredictable, a simple counter is often used. As an example, a block encryption function (like the ubiquitous AES) can be used to produce a large stream of pseudorandom numbers by simply encrypting consecutive nonces 1. As long as the encryption key remains secret and the nonce is never repeated, the output is unpredictable even though the input is completely predictable.

In some cases, the nonce has a secondary non-cryptographic purpose where the order also matters. For example, every transaction signed by an Ethereum address contains a nonce, which ensures that each signature is unique, even if there are multiple transactions with identical contents. However, the nonce is also used to order the transactions, so it’s called a sequence number instead.

Salts

Salts are unpredictable values that are not treated as secrets. Their purpose is to anchor cryptographic primitives to a particular use case.

One common example is when an authentication server stores hashes of user passwords so that they can be compared against future login attempts. The hashes themselves are typically not considered secrets since they must be directly available to the authentication server.

Hash functions

https://learncryptography.com/encryption#hash-functions

https://learncryptography.com/hash-functions/what-are-hash-functions

A hash function is simply a function that takes in input value, and from that input creates an output value deterministic of the input value. For any x input value, you will always receive the same y output value whenever the hash function is run. In this way, every input has a determined output. 

A function is basically something that takes an input and from that input derives an output. 

A hash function is therefore something that takes an input (which can be any data - numbers, files, etc) and outputs a hash. A hash is usually displayed as a hexadecimal number.

This is the hash function md5, which from any input data creates a 32 character hexadecimal output. Hash functions are generally irreversible (one-way), which means you can’t figure out the input if you only know the output – unless you try every possible input (which is called a brute-force attack). 

Hash functions are often used for proving that something is the same as something else, without revealing the information beforehand. Here’s an example.

Let’s say Alice is bragging to Bob that she knows the answer to the challenge question in their Math class. Bob wants her to prove that she knows the answer, without her telling him what it is. So, Alice hashes her answer (let’s say the answer was 42) to produce this hash:

Alice gives this hash to Bob. Bob can not find out what the answer is from this hash – but when he finds the answer himself, he can hash his answer and if he gets the same result, then he knows that Alice did indeed have the answer. Hashes are often used in this context of verifying information without revealing it to the party that is verifying.

Homomorphic encryption

https://en.wikipedia.org/wiki/Homomorphic_encryption

Homomorphic encryption is a form of encryption that allows computation on ciphertexts, generating an encrypted result which, when decrypted, matches the result of the operations as if they had been performed on the plaintext.

Homomorphic encryption can be used for privacy-preserving outsourced storage and computation. This allows data to be encrypted and out-sourced to commercial cloud environments for processing, all while encrypted. In highly regulated industries, such as health care, homomorphic encryption can be used to enable new services by removing privacy barriers inhibiting data sharing. For example, predictive analytics in health care can be hard to apply due to medical data privacy concerns, but if the predictive analytics service provider can operate on encrypted data instead, these privacy concerns are diminished.

MFA - Multi-Factor Authentication schemes

https://techcommunity.microsoft.com/t5/Azure-Active-Directory-Identity/All-your-creds-are-belong-to-us/ba-p/855124?MC=Windows&MC=MSAzure&MC=Virtual&MC=SQL&MC=OfficeO365

Microsoft - good piece on MFA - Multi Factor Authentication schemes and how susceptible they are to channel jacking or real-time phishing attacks

Passwords - Salted, Hashed

https://learncryptography.com/hash-functions/password-salting

Password salting is the process of securing password hashes from something called a Rainbow Table attack. The problem with non-salted passwords is that they do not have a property that is unique to themselves – that is, if someone had a precomputed rainbow table of common password hashes, they could easily compare them to a database and see who had used which common password. A rainbow table is a pre-generated list of hash inputs to outputs, to quickly be able to look up an input (in this case, a password), from its hash. However, a rainbow table attack is only possible because the output of a hash function is always the same with the same input.

So how do we make each hashed password in a database unique? We add something called a salt to the input to the hash function. A salt is basically some random data that is unique to each user, that is saved with their password and used in the hashing process of both storing and verifying the password. Why is this effective?

Every user now has something that is unique to them, that is added on to their password before it is hashed and stored in the database. Now, if someone were to try to compare the database password hashes with a list of common password hashes – none of the hashes would match, even if users had used common passwords in the attackers list. The salt completely changes the output of the hash function, meaning that an attacker would have to brute force the password of each user individually, effectively eliminating the benefit of a rainbow table. 

Some MFA methods are less secure - 2022

https://arstechnica.com/information-technology/2022/03/lapsus-and-solar-winds-hackers-both-use-the-same-old-trick-to-bypass-mfa/

Multi-factor authentication (MFA) is a core defense that is among the most effective at preventing account takeovers. In addition to requiring that users provide a username and password, MFA ensures they must also use an additional factor—be it a fingerprint, physical security key, or one-time password—before they can access an account. Nothing in this article should be construed as saying MFA isn’t anything other than essential.

That said, some forms of MFA are stronger than others, and recent events show that these weaker forms aren’t much of a hurdle for some hackers to clear. In the past few months, suspected script kiddies like the Lapsus$ data extortion gang and elite Russian-state threat actors (like Cozy Bear, the group behind the SolarWinds hack) have both successfully defeated the protection.

The strongest forms of MFA are based on a framework called FIDO2, which was developed by a consortium of companies balancing the needs of both security and simplicity of use. It gives users the option of using fingerprint readers or cameras built into the devices or dedicated security keys to confirm they are authorized to access an account. FIDO2 forms of MFA are relatively new, so many services for both consumers and large organizations have yet to adopt them.

That’s where older, weaker forms of MFA come in. They include one-time passwords sent through SMS or generated by mobile apps like Google Authenticator or push prompts sent to a mobile device. When someone is logging in with a valid password, they also must either enter the one-time password into a field on the sign-in screen or push a button displayed on the screen of their phone.

Zero Trust Concepts & Architecture 

zero-trust-data-security-for-dummies.pdf. link

zero-trust-data-security-for-dummies.pdf. file

Recognizing the Need for Zero Trust Data Security__________........... 3
Understanding Zero Trust Data Security_____....... 3
Identifying Challenges with Legacy Backup _____.. 6
Looking at Data Security Issues _____...................... 7
Realizing the Benefits of Zero Trust Data Security........................... 8

Understanding Zero Trust Data
Security Architecture _____........................... 9
Zero Trust Data Protection_____.............................. 9
Ransomware Investigation_____............................ 10
Sensitive Data Discovery _____............................... 13
Incident Containment __________ 16

Orchestrated Application Recovery _____............. 16
Getting Started with Zero Trust
Data Security__________......... 19
Safeguarding Data with Immutability and Data Availability ......... 19
Discovering Data Anomalies with Machine Learning .................... 22
Classifying Data and Assessing Exfiltration Risk............................. 22
Hunting for Threats to Prevent Reinfection _____ 24
Recovering Apps and Data with Guided Workflows ...................... 24

Ten Keys to Response Preparedness ......................... 27

EO-14028, Improving the Nation’s Cybersecurity order url

Sec. 2. Removing Barriers to Sharing Threat Information.
Sec. 3. Modernizing Federal Government Cybersecurity.
Sec. 4. Enhancing Software Supply Chain Security.
Sec. 5. Establishing a Cyber Safety Review Board.
Sec. 6. Standardizing the Federal Government’s Playbook for Responding to Cybersecurity Vulnerabilities and Incidents.
Sec. 7. Improving Detection of Cybersecurity Vulnerabilities and Incidents on Federal Government Networks.
Sec. 8. Improving the Federal Government’s Investigative and Remediation Capabilities.
Sec. 9. National Security Systems - adopt higher security requirements
Sec. 10. Definitions.

EO-14028, Improving the Nation’s Cybersecurity Overview url

https://www.whitehouse.gov/briefing-room/statements-releases/2022/01/19/fact-sheet-president-biden-signs-national-security-memorandum-to-improve-the-cybersecurity-of-national-security-department-of-defense-and-intelligence-community-systems/

This NSM requires that, at minimum, National Security Systems employ the same network cybersecurity measures as those required of federal civilian networks in Executive Order 14028. The NSM builds on the Biden Administration’s work to protect our Nation from sophisticated malicious cyber activity, from both nation-state actors and cyber criminals.

EO-14028, Improving the Nation’s Cybersecurity fact sheet url

https://www.whitehouse.gov/briefing-room/statements-releases/2021/05/12/fact-sheet-president-signs-executive-order-charting-new-course-to-improve-the-nations-cybersecurity-and-protect-federal-government-networks/

NIST 800-207 on Zero Trust Architecture

https://www.nist.gov/news-events/news/2020/08/zero-trust-architecture-nist-publishes-sp-800-207

NIST announces the final publication of Special Publication (SP) 800-207, Zero Trust Architecture, which discusses the core logical components that make up a zero trust architecture (ZTA). Zero trust refers to an evolving set of security paradigms that narrows defenses from wide network perimeters to individual or small groups of resources. Its focus on protecting resources rather than network segments is a response to enterprise tends that include remote users and cloud-based assets that are not located within an enterprise-owned network boundary. ZTA strategies are already present in current federal cybersecurity policies and programs, though the document includes a gap analysis of areas where more research and standardization are needed to aid agencies in developing and implementing ZTA strategies. Additionally, this document establishes an abstract definition of zero trust and ZTA as well as general deployment models, use cases where ZTA could improve an enterprise’s overall IT security posture, and a high-level roadmap to implementing a ZTA approach for an enterprise.

NIST.SP.800-207-zero-trust-paper-2020.pdf link

https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf

Zero trust (ZT) is the term for an evolving set of cybersecurity paradigms that move defenses
from static, network-based perimeters to focus on users, assets, and resources. A zero trust
architecture (ZTA) uses zero trust principles to plan industrial and enterprise infrastructure and
workflows. Zero trust assumes there is no implicit trust granted to assets or user accounts based
solely on their physical or network location (i.e., local area networks versus the internet) or based
on asset ownership (enterprise or personally owned). Authentication and authorization (both
subject and device) are discrete functions performed before a session to an enterprise resource is
established. Zero trust is a response to enterprise network trends that include remote users, bring
your own device (BYOD), and cloud-based assets that are not located within an enterprise owned network boundary. Zero trust focuses on protecting resources (assets, services,
workflows, network accounts, etc.), not network segments, as the network location is no longer
seen as the prime component to the security posture of the resource. This document contains an
abstract definition of zero trust architecture (ZTA) and gives general deployment models and use
cases where zero trust could improve an enterprise’s overall information technology security
posture.

ZTA may use enhanced identity governance

The enhanced identity governance approach to developing a ZTA uses the identity of actors as the key component of policy creation. If it were not for subjects requesting access to enterprise resources, there would be no need to create access polices. For this approach, enterprise resource access policies are based on identity and assigned attributes. The primary requirement for resource access is based on the access privileges granted to the given subject. Other factors such as device used, asset status, and environmental factors may alter the final confidence level calculation (and ultimate access authorization) or tailor the result in some way, such as granting only partial access to a given data source based on network location. Individual resources or PEP components protecting the resource must have a way to forward requests to a policy engine service or authenticate the subject and approve the request before granting access.

Zero Trust Concepts - Crowdstrike

https://www.crowdstrike.com/cybersecurity-101/zero-trust-security/

Zero Trust Concepts 2022 - Crowdstrike file

Zero Trust Concepts 2022 - Crowdstrike link

Zero Trust is a security framework requiring all users, whether in or outside the organization’s network, to be authenticated, authorized, and continuously validated for security configuration and posture before being granted or keeping access to applications and data. Zero Trust assumes that there is no traditional network edge; networks can be local, in the cloud, or a combination or hybrid with resources anywhere as well as workers in any location.

Zero Trust is a framework for securing infrastructure and data for today’s modern digital transformation. It uniquely addresses the modern challenges of today’s business, including securing remote workers, hybrid cloud environments, and ransomware threats. While many vendors have tried to create their own definitions of Zero Trust, there are a number of standards from recognized organizations that can help you align Zero Trust with your organization.

Zero Trust seeks to address the following key principles based on the NIST guidelines:

1. Continuous verification.  Always verify access, all the time, for all resources.
2. Limit the “blast radius.”  Minimize impact if an external or insider breach does occur.
3. Automate context collection and response.  Incorporate behavioral data and get context from the entire IT stack (identity, endpoint, workload, etc..) for the most accurate response.

You are required to protect an infrastructure deployment model that includes:

• Multi-cloud, hybrid, multi-identity
• Unmanaged devices
• Legacy systems
• SaaS apps

You need to address key threat use cases including:

• Ransomware – a two-part problem involving code execution and identity compromise
• Supply chain attacks – typically involves unmanaged devices and privileged users working remotely
• Insider threats – especially challenging to analyze behavioral analytics for remote users

How Zero Trust Works

Execution of this framework combines advanced technologies such as risk based multi-factor authentication, identity protection, next-generation endpoint security, and robust cloud workload technology to verify a user or systems identity, consideration of access at that moment in time,  and the maintenance of system security. Zero Trust also requires consideration of encryption of data, securing email, and verifying the hygiene of assets and endpoints before they connect to applications.

Zero Trust ( like AATR - Access Appropriate To Role ) enforces the principle of least privilege mandate strict policies and permissions for all accounts,

Trust Engineering implements Zero Trust Solutions using STEAR

S = survey and secure environment and assets and set security policies

T = trace access requests, grants, access, threats, breaches, policy effectiveness

E = escalate policy violations and identified threats based on appropriate severity and responsibilities

A = accountability - use audits to verify managers of trust have been effective, identified gaps and closed them on a priority basis

R = remediate - fix any access control issues,  fix data plane problems using recovery models

Trust Engineering Process

follow STEAR process above

• in each area and logical layer, topic define the asset, resource stereo types
• for each stereo type, define the threats, proofs to measure the threat and security, policies to implement the proofs at appropriate control points
• for each asset or resource, determine if customized policy management rules are needed

Zero-Trust Security Model for Microservices

https://drive.google.com/open?id=1f7OGCWYKLrLDU6_UPMJNfGivdQ0Ec8de

to implement a zero-trust model, security and operations teams willneed to focus on two key concepts. First, security will need to be integrated into the workloads themselves, and will move with the instances and data as they migrate between internal and public cloud environments. Second, the actual behavior of the applications and services running on each system will need to be much better understood, and the relationships between systems and applications will need more intense scrutiny than ever to facilitate a highly restricted, zero-trust operations model.

JWT Token-based Authentication

https://auth0.com/learn/token-based-authentication-made-easy/

A token is a piece of data that has no meaning or use on its own, but combined with the correct tokenization system, becomes a vital player in securing your application. Token based authentication works by ensuring that each request to a server is accompanied by a signed token which the server verifies for authenticity and only then responds to the request.

JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained method for securely transmitting information between parties encoded as a JSON object. JWT has gained mass popularity due to its compact size which allows tokens to be easily transmitted via query strings, header attributes and within the body of a POST request.

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJtZXNzYWdlIjoiSldUIFJ1bGVzISIsImlhdCI6MTQ1OTQ0ODExOSwiZXhwIjoxNDU5NDU0NTE5fQ.-yIVBD5b73C75osbmwwshQNRC7frWUYrqaTjTpza2y4

// Load in our dependencies
var express = require('express');
var jwt = require('jsonwebtoken');

var app = express();

// Register the home route that displays a welcome message
// This route can be accessed without a token
app.get('/', function(req, res){
  res.send("Welcome to our API");
})

// Register the route to get a new token
// In a real world scenario we would authenticate user credentials
// before creating a token, but for simplicity accessing this route
// will generate a new token that is valid for 2 minutes
app.get('/token', function(req, res){
  var token = jwt.sign({username:"ado"}, 'supersecret',{expiresIn: 120});
  res.send(token)
})

// Register a route that requires a valid token to view data
app.get('/api', function(req, res){
  var token = req.query.token;
  jwt.verify(token, 'supersecret', function(err, decoded){
    if(!err){
      var secrets = {"accountNumber" : "938291239","pin" : "11289","account" : "Finance"};
      res.json(secrets);
    } else {
      res.send(err);
    }
  })
})

// Launch our app on port 3000
app.listen('3000');

// Load in our dependencies
var express = require('express');
var jwt = require('express-jwt');

var jwtCheck = jwt({
  secret: new Buffer('{YOUR-APP-SECRET}', 'base64'),
  audience: '{YOUR-APP-CLIENT-ID}'
});

var app = express();

// Rather than checking for a token within our controller
// we'll use a middleware so if the token is invalid we'll
// stop further execution of the request
app.use('/api', jwtCheck);

app.get('/', function(req, res){
  res.send("Welcome to our API");
})

app.get('/api', function(req, res){
  var secrets = {"accountNumber" : "938291239","pin" : "11289","account" : "Finance"};
  res.json(secrets);
})

app.listen('3000');

var domain = '{YOUR-AUTH0-DOMAIN}.auth0.com';
var clientID = '{YOUR-APP-CLIENT-ID}';

var lock = new Auth0Lock(clientID, domain);
lock.show({
  focusInput: false,
  popup: true,
}, function (err, profile, token) {
  alert(token)
});

API Security Tokens

https://id.atlassian.com/manage/api-tokens

A script or other process can use an API token to perform basic authentication with Jira Cloud applications or Confluence Cloud. You must use an API token if the Atlassian account you authenticate with has had two-step verification enabled. You should treat API tokens as securely as any other password.

Learn more

https://confluence.atlassian.com/cloud/api-tokens-938839638.html

You can use an API token to authenticate a script or other process with an Atlassian cloud product. You generate the token from your Atlassian account, then copy and paste it to the script.

If you use two-step verification to authenticate, your script will need to use a REST API token to authenticate.

Create an API token

Create an API token from your Atlassian account:

1. Log in to https://id.atlassian.com/manage/api-tokens.
2. Click Create API token.
3. From the dialog that appears, enter a memorable and concise Label for your token and click Create.
4. Click Copy to clipboard, then paste the token to your script, or elsewhere to save:
   
   

Note:

• For security reasons it isn't possible to view the token after closing the creation dialog; if necessary, create a new token.
• You should store the token securely, just as for any password.
  

  Use an API token

  A primary use case for API tokens is to allow scripts to access REST APIs for Atlassian cloud products using HTTP basic authentication.

  Depending on the details of the HTTP library you use, simply replace your password with the token. For example, when using curl, you could do something like this:

  curl -v https://mysite.atlassian.net --user me@example.com:my-api-token

  Note that me@example.com here is the email address for the Atlassian account you're using to create the token.

IBM i Security Best Practices

https://www.slideshare.net/Syncsort/best-practices-in-ibm-i-security?from_action=save

IoT Security Architectures

SASE - distributed security - Secure Access Service Edge

https://www.forbes.com/sites/richardstiennon/2019/12/09/gartner-has-it-right-palo-alto-networks-has-it-wrong/#5eeefb8ec195

sase-cloud-iot-security-forbes.com-Gartner Has It Right Palo Alto Networks Has it Wrong.pdf

SASE roadmap 2024 - Gartner

Potential Value Opportunities

Development, Deployment Security Reviews

Paramount performs static and dynamic analysis on blockchain solutions including:

1. Paramount teams run OWASP analysis on the applications to find and remediate any security vulnerabilities
2. Data security and data quality tests are run on the data stores, DLT ledger
3. CRL tests on certificates for members
4. Validation tests on signed transactions and TLS connections are also done

Runtime Security Reviews

Paramount blockchain solutions can include runtime dynamic security validations and remediations covering:

1. Pen Tests for environments
2. Options exist for multi-factor authentication and CAPTCHA challenges
3. Authentication session tokens can be expired based on time or security events
4. Validation of blockchain principal identities on transactions
5. Validation blockchain transactions are signed by legitimate certificate users
6. Validation blockchain smart contract updates are approved meeting network policy controls
7. Dynamic log levels based on policies for threat profiles for later SIEM analysis
8. Some solutions have incorporated fine-grained data authorizations beyond basic functional authorizations that are common
9. Embedded data quality and validation tests have been included in some solutions raising incidents for SIEM analysis
10. A future release of Hyperledger Fabric will add support for TEE ( Trusted Execution Environments ) providing full security for data at-rest, in-flight and in-memory running smart contracts in a secure enclave

Potential Challenges

OWASP solution analysis

https://owasp.org/www-project-web-security-testing-guide/assets/archive/OWASP_Testing_Guide_v3.pdf

SANS 25 Top Security Threats

https://www.sans.org/blog/top-25-series-summary-and-links/

What is STRIDE and How Does It Anticipate Cyberattacks?

https://securityintelligence.com/articles/what-is-stride-threat-modeling-anticipate-cyberattacks/

security-threat-models-securityintelligence-What is STRIDE and How Does It Anticipate Cyberattacks.pdf

Spoofing identity, Tampering with data, Repudiation threats, Information disclosure, Denial of service and Elevation of privileges

Threat modeling

• spot threats during the design phase of an app or system. 
• The first step helps find potential threats using a proactive process. The design of the system forms the basis for spotting threats.
• The next steps include finding the risks inherent in the way the system has been implemented, and then taking actions to close gaps.

Penetration Testing By Layer ( Net, Services, App svcs ( ssh etc ), Roles, Data access logs ) 

IBM i Pen testing concepts

Securing IBM i: A Dual Responsibility.pdf 

The easiest way to be aware of your PTF levels is to use the following IBM i Service which does a ‘phone home’ to IBM to find the most recent PTFs and compares that list to what’s installed.

SELECT * FROM SYSTOOLS.GROUP_PTF_CURRENCY ORDER BY PTF_GROUP_LEVEL_AVAILABLE - PTF_GROUP_LEVEL_INSTALLED DESC; Unfortunately, there is an occasional defective PTF, so another service has been created that looks at defective PTFs and shows whether the replacement PTF is installed.

SELECT * FROM SYSTOOLS.DEFECTIVE_PTF_CURRENCY;

You can even determine your firmware levels

SELECT * FROM SYSTOOLS.FIRMWARE_CURRENCY;

Meeting - IBM i Pen testing concepts

Securing IBM i: A Dual Responsibility

Candidate Solutions

CSA - Cloud Security Alliance  - Security, Trust, Assurance and Risk (STAR)

Security, Trust, Assurance and Risk (STAR)
The industry's most powerful program for security assurance in the cloud.

The Security, Trust, Assurance, and Risk (STAR) Registry is a publicly accessible registry that documents the security and privacy controls provided by popular cloud computing offerings.

STAR encompasses the key principles of transparency, rigorous auditing, and harmonization of standards outlined in the Cloud Controls Matrix (CCM). Publishing to the registry allows organizations to show current and potential customers their security and compliance posture, including the regulations, standards, and frameworks they adhere to. It ultimately reduces complexity and helps alleviate the need to fill out multiple customer questionnaires.

Level 1 - self assessment with cloud security standards 

Level 2 - audited proof of compliance with cloud security standards

Which organizations should pursue level 2?

Organizations should pursue this level if they are...

• Operating in a medium to high risk environment
• Already hold or adhere to the following: ISO27001, SOC 2, GB/T 22080-2008, or GDPR
• Looking for a cost-effective way to increase assurance for cloud security and privacy.

Step-by-step guide for Example

sample code block

Recommended Next Steps

General Notes to create Security Topic 

jim.mason [8:17 AM]
Things like RansomWare and Denial of Service are general security threats - nothing specific to blockchain .. they are really part of a Security course for sure

ECDSA is just a blockchain algorithm used by some other blockchain frameworks. For us, it's only a glossary item at most
this glossary is a start for some concepts but we should provide extensions to this for concepts like ECDSA and more .. https://hyperledger-fabric.readthedocs.io/en/latest/glossary.html

jim.mason [8:28 AM]
I do think Chapter 11 on Security is good for reference concepts for developers. If this were an admin course, we would expect more hands-on skill sets for security and network configuration beyond the basics of setting up a test network and issuing certificates using the CA support delivered with Fabric.

Omar [8:41 AM]
Agreed

jim.mason [8:49 AM]
I could draft a "simple" security section ( not part of the blockchain courses, books ) that goes through the basics of Internet security and encryption by harvesting existing open source resources ... What I don't like about the IBM books, or Udemy course etc is they all provide security definitions narrowly defined for just their context ( as they should ). A "limited" primer on Internet security, authentication, authorization and encryption borrowing from open source references would be good for people to read and be quizzed on content for understanding -- no coding exercises needed .. your thoughts ???
More advanced developers can skip this and "quiz" their way out without reading the material if that made sense

Omar [8:51 AM]
I would agree to the security section.
Although I would have all users take it no matter their expertise

jim.mason [8:52 AM]
I can try to have a draft ready for next Wednesday for you to review
I'm literally harvesting a good set of open source materials for the concepts and creating a quiz on the concepts. Then when you move into specific activities in Hyperledger related to security you would have a reasonable understanding of the context

Omar [8:54 AM]
Sounds good

Related articles