What is technical debt? and how to handle it

Overview: Technical Debt generally refers to a buildup of deficiencies that makes changing code or optimizing systems difficult.  The key is to identify what in you organisation/program/project makes up technical debt.  

Technical Debt generally refers to poor or missing NFRs such as Performance, Security, Maintainability, Reliability, Scalability,  Testability, or Resiliency.  But it also can go further into future architecture, so if this part of our system is popular can we easily adjust and keep releasing features.  So as you can see, technical debt can be very wide and it's far better to focus a subset otherwise PO and PM's tend to scope everything under technical debt and wit gets nasty telling them about "additional technical debt".

I find the easier way to go about defining what is technical debt to avoid long discussions to to list out what cannot be considered technical debt.  This would be my minimum starting point:

1. Bugs (Functional defects);
2. Technical Skill Debt;
3. Process Defects (Lack of process or poor process, such as Configuration Management);
4. Feature Debt (Wrong or delayed features or missing functionality (recent favorite example is "how can a system not have customer off boarding it's obviously technical debt", this is feature debt, make sure stakeholders know or it falls into the old IT/Dev are weak and missed things description.); and
5. UI/UX Defects (Inconsistent or poor or changing user experience).

Another items is spaghetti code that falls under the NFR of code maintainability, with old systems you have to be pragmatic, if the product brings in $100k per year it's not a good idea to spend $120k a year making the code more readable but not improving the technology as a general rule.  On old systems, I try to keep code maintainability out of the technical debt,.  You should put it to another more detailed section, just don't lump everything especially when it is huge changes all under technical debt.  Dev teams loose focus and it causes problems don the line.  All too often, over exercised bundling debt pushed into technical debt results in "even more interest to pay later".

Azure Application Gateway Basics

Azure Application Gateway is a http traffic load balancer that allows me to manage my web traffic.  So based on urls, paths, the traffic can be pushed on accordingly.  It also provides for sticky sessions.  In my head I see Azure Application Gateway as a layer 7 HTTP Load Balancer and a Web Application Firewall (WAF).  There are 3 core concepts: Front-ends, rules and backends that are used to route traffic from the front-end to the back-ends.

Azure Load Balancer works at level 4 where Azure application gateway is for web traffic at layer 7 of the OSI model.

Azure Front Door is basically for world wide Application gateway functionality.

Checklist on the Application Gateway: 

• You should enable the WAF unless you already use another WAF like Imperva enterprise wide, do this under the "Web application firewall" option, setup OWASP rules.  
• Config session affinity, and HTTPS termination using the "HTTP settings".  
• "Listeners"  are what listens for incoming http requests.
• "Rules" bind the listeners to the backend pools.
• "Backend pools" are used to point traffic to the end points.  Also remember to setup "Health Probes", this allows the App pool to verify the backends are working.
•  Ensure you set the diagnostics logging to send logs to "Log Analytics" so you can examine the logs.

Features: 

1. SSL/TLS termination - Terminate SSL using certificate
2. Autoscaling - increase the size or instance count based on traffic requirements
3. Can be setup to be zone redundant
4. Static IP address that doesn't change
5. WAF and DDoS (pretty new 2022, applied using Azure DDoS Sentinel service) capabilities - The WAF allows you to apply OWASP rules and add additional custom rules.  Bot protection is also built in, rules need to be applied to get it to work.  
6. URL-based routing
7. Multiple domains/site hosting
8. Redirection
9. Sticky sessions/session affinity
10. HTTP/2 support
11. Custom error pages (so useful)
12. Rewrite headers and URL

References:

How an application gateway works | Microsoft Docs

WAF options

Personal Access Tokens (PAT)

Personal Access Token (PAT) are used a lot for automation in DevOps, once again need to lookup the informal on PATs.  I use Postman and I use PATs to automate connecting to Azure resources.

https://learn.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops&tabs=Windows

Store the PAT as it won't be retrievable again.

Microsoft Sentinel - Introduction

Overview: Microsoft Sentinel is Microsoft's cloud hosted SIEM solution.  It can take data from Azure, on-prem., and other cloud infrastructure such as AWS.  Sentinel gathers data from various sources, and evaluates to generate alerts.  

SIEM allows software products and services to bring security information/events into a management tool to provide real-time analysis of security from all applications and networks across the enterprise.  SIEM stands for security, information, and event management and is commonly used by the COS (Security Operations Teams of a business), the SOC is often outsourced or partially outsourced to Service companies e.g. Avanade are good at this.  Other SIEM products are: SolarWinds security and monitoring (great product), McAfee ESM, Rapid7, Splunk, and Datadog.  There on installable and SaaS solutions but I prefer SaaS solution like Microsoft Sentinel.  AWS and Google also provide SIEM services.

Microsoft Sentinel (previously called Azure Sentinel) is cloud-native and collects SIEM data from systems, applications and networking to provide an overview of the organizations security alerts, and allows identification for remediation.  It accepts several common formats for capturing events and offers a REST - API.  Sentinel also has a ton of native connectors.

"Microsoft Sentinel is a scalable, cloud-native, security information and event management (SIEM) and security orchestration, automation, and response (SOAR) solution." Microsoft Docs

Simple Password protection got GTM - Starting Page

Overview:  I am use the AuthPro service to check a user has a code to access the website.  This is useful for Go to Market (GTM) where you only want a subset of customers to work on your software.  Think of a beta where a user can sign up, you give people with an NDA a code to be able to go thru the sign-up process.

Simple solution:  

To get to the sign-up/register page, use an external service e.g. AuthPro to manage a passcode.  AuthPro injects JS and allows the admin to configure the behavior.  It was pretty simple to setup so only specified users could go thru our sign up process.

Demo:  This page allows the user to login, if, successful the user can proceed and use the website.

Type in the username "password" and the password "password" for access to the hidden page.  

Another Option: Imperva has a lot of features including "Login protection" that can easily achieve the same outcome.

NIST/RMF - Cyber risk control

Overview: NIST National Institute of Standards and Technology - Provides Risk Management Framework (RMF) - Is a framework to reduces security risk to systems and data.

Goals of NIST RMF:

• Consistent and cost effective set of security controls
• Repeatable assessment approach
• Technology neutral
• Implement an efficient risk-based security and privacy program.

Notes:

• Each of these six steps have Special Publications (SP) that are applicable to the area.
• The core document to for RMF is NIST SP 800-37 Revision 2. 
• Used to identify security/pricacy risks at both the operation and system level 

OWASP top 10 - 2021

 Always verify your system's have reviewed the OWASP top 10 vulnerabilities 2021: 

1. Broken Access Control (ensure users only see what they should have access too).  Permission need to be correctly specified and enforced.  i.e. don't allow customers to have Admin account privileges or access to another customers details.  Security needs to allow enough right/privileges so people and clients can do what they need to but must not over allow privileges.  Prevention techniques must include least privilege (no access by default and give the minimum needed permissions), audit access and changes (think tomb tables/temporal changes) but can also include access auditing and logging access control changes.  Lastly, QA must verify permissions work as expected, so often it is just assume it works as the QA thinks and not to actual policy/specification), 
2. Cryptographic failure (data in transit and at rest must be securely encrypted, more sensitive data must be more encrypted/scrambled.  By default everything should be encrypted but add extra encryption/controls to sensitive information like passwords.  For payment processing use a specialist provide like Stripe.  Encryption can be symmetric or asymmetric.  Ensure you use algorithms that are considered weak such as Triple DES also known as 3DES rather use AES, or hashing Algorithms such as SHA1 and RIPEMD160 are weak, rather use a SHA2 algorithm.  Manage your keys properly such as Azure Key Vault and rotate the keys regularly.  Salt hash key data to have encryption and hashing on sensitive data), 
3. Injection (data input results in unintended processing) examples are SQL injections and Cross side scripting (XSS),
4. Insecure Design (new addition in 2021, don't include sensitive information in error messages, ensure architecture can scale, passwords stored in plain text or are not rotatable, deal with DDoS, if 1 part of an app brings the whole solution down),
5. Security misconfiguration (default setup that is not very secure e.g. default password is not changed on installed software, ensure security hardening happens.  I.e. short passwords, changing passwords, updating software,...)
6. Vulnerable outdated components (we use components in code, if they have security weaknesses it's likely you also have it Log4J was an example.  You need to know all you supply chain dependencies so you need to ensure they are not vulnerable.  SAST scanning tools help identify vulnerabilities.  Know your component dependencies!), 
7. Identification & authorisation failures (You are who you say you are, check claims, use OAuth, OIDC example is session hijacking or stealing someone else's identification, public pc, next user logs in as you previous user),
8. Software and Data integrity failures (insured CI/CD pipeline, closely linked to item 6. example, could automatically update a nugget package to the latest automatically which has a security flaw in it),
9. Security Logging and Monitoring failures (check logs to detect security issues, incidents will happen and can often see people scanning for vulnerabilities),
10. Server-side Request Forgery (SSRF) (servers ask for endpoint info, use only-allow in headers or only allow the specific IP of the partner, ensure only relevant info is returned).