Role of a Solution Architect in Modern Organizations

This week came across a topic of how the market lacks good Solutions Architects and how the role of a Solution Architect is often misused in the IT industry, especially with the advent of cloud certifications. With Agile Organizations, the role of the Solution Architect also seems to be diminishing. It has also led to organizations creating other different Architecture titles doing specific tasks.

Having played the role of Solution Architect for about a decade now, I feel the title typically requires years of experience designing and implementing complex software solutions in different projects and domains. 

Solution Architect Mindset

It involves a deep understanding of Business requirements, Technical constraints, Architecture Design and Principles, and staying up-to-date on Emerging Technologies. Solution Architects must also possess strong communication and leadership skills to work effectively with Stakeholders, Developers, Business Architects, and other team members.

With the rise of cloud certifications, many individuals get the title of Solution Architect without the necessary experience and expertise. It is probably the main reason that has led to a proliferation of Solution Architects who lack the required skills to design and implement complex solutions. 

Also, Organizations do not clearly define the roles and responsibilities of a Solution Architect. The role has evolved in the past decade with emerging technologies and ways of working, but the fundamentals have always remained the same. 

By definition, a Solution Architect's role is to design and oversee the implementation of software solutions that meet business requirements. To think like a modern Solution Architect, for any project, one has to mold in the below five areas. 

a) Understanding Business Requirements

b) Evaluate the requirements based on the abilities

c) Define the Architecture principles of the solution

d) Define the Architecture and design the overall solution

e) and Participate in the development of end-to-end solution

Conclusion

In conclusion, to have a successful Solution Architect mindset, one needs to ensure they have the problem-solving ability, love having strategic thinking proficiency, have proper communication to collaborate, and have the urge for continuous learning. 

Choosing between Azure function App or Azure App Service for your application

This week for building a client-facing mobile app, I had a choice of using either a PaaS or a Serverless implementation on Microsoft Azure This week to create a client-facing mobile application, I had a choice of using either a PaaS or a Serverless implementation on Microsoft Azure Cloud. 

One of the development teams wanted to use an Azure Function, and the other wanted to go with the simple Azure App service plan. It was not the first use case wherein I had to choose between the two services. Serverless technology has evolved and is no longer used just for independent worker-based functionalities. I have used it for several different use cases, including building a part of an e-commerce site running purely on serverless technology. 

I had to take in all the pros and cons and take a logical view to choose between the two. 

Step 1: 

I started to understand the abilities based on the granularity of the business requirements

What are the requirements?

a.    Business logic - Does the application require a full-fledged middleware with data and business logic?

b.   Lightweight system - Is the application more of a lightweight web API system?

c.    Expected Traffic - What will be the dedicated traffic towards the application?

d.   Code complexity - Does the application require a small piece of code or function for every request?

e.    Performance - Does the application require quick responses?

f.    Scalability- What are the scalability requirements?

g.   Ease of Development/Deployment - What is the level of ease of deployment and development?

h.   Security - What are the security requirements?

i.     Cost - What are the budget or cost requirements?

j.     Application Design - Complexity of the application design?

k.   Governance - Is governance an issue? Are there multiple teams owning and deploying modules to production regularly?

l.     Maintenance - Who will maintain the application, and what are the SLAs?

m. Redundancy- What are the application redundancy requirements?

n.   Technology - Is there a technology restriction?

o.   Learning curve – Technology adaption and learning curve requirements?

Step 2: 

As the requirements are understood, the next step is to understand and map the capabilities and challenges and compare the two services in the context of the development teams.

The Azure function has Three plans -> 1. Consumption 2. Premium, and 3. App service plan

a.    Plan fitment: The consumption plan has cold start issues, less security, and less cost. So, this has to be considered before going with this plan for a production-ready product. Neither cold starts nor security is an issue in building applications with App service.

b.   Cost Issue: Premium and App service plans can avoid cold starts. They also provide better security (with VNET) but at a higher cost. The cost is the same as the App service plan. 

c.    Complexity: With Azure functions, if several moving parts are created, and limited people are maintaining it, then it can get complex. 

d.   Governance issue in the future: If we are building independent decentralized functions, standardization can be an issue in the future.

e.    Latency: If a function in the future needs to wait for another function to execute, then the latency becomes an issue and complexity as well.

f.    Future Business logic: If writing business logic requires building several functions or classes, then an app service integration will be the way to go.

g.   Learning curve and support: It can become a learning curve issue for someone new to maintain and support the applications with multiple functions.

Concluding, both services offer several similar features, In our case, the application was simple and had some future business requirements that required processing with no end-user impact, so the App Service seemed to be an apt fit. However, the choice could be totally different for another set of requirements. 

                                                     

Securing Public Website Domain - Part 3 - DNSSEC

The third part of this series is regarding DNSSEC. Every time the browser requests a website, it goes via a DNS. Since DNS is mostly an outsourced component, we hardly ever worry about its scalability and security. On evaluating a clients website for modern and reliable internet standards for DNS security, the first error had the following information:-

Too bad! Your domain is not signed with a valid signature (DNSSEC). Therefore visitors with enabled domain signature validation, are not protected against manipulated translation from your domain into rogue internet addresses. 

What is DNNSEC?

The Domain Name System Security Extensions (DNSSEC) is a critical technology to secure the Domain Name System (DNS). DNSSEC provides a layer of authentication and integrity checking to the DNS, ensuring that the information transmitted is trustworthy and has not been tampered with. 

To enable DNNSEC, the domain registrar or the hosting provider should do that. 

Vulnerabilities due to a domain not being signed with a valid signature?

While DNSSEC has been available for many years, it is surprising that many known websites still need this signature from the DNS provider. These include major cloud providers like https://www.amazon.com, https://www.microsoft.com, and DNS providers like https://www.godaddy.com. 

As per https://internet.nl/faqs/dnssec/, some real-world incidents that DNSSEC could have prevented include

• "Cache-poisoning attack snares top Brazilian bank"
• "Eircom reveals ‘cache poisoning’ attack by hacker led to outages"
• "DNS cache poisonings foist malware attacks on Brazilians"
• "Probable Cache Poisoning of Mail Handling Domains"
• "Neither Snow Nor Rain Nor MITM... An Empirical Analysis of Email Delivery Security

One of the primary issues with not implementing DNSSEC is DNS cache poisoning. It occurs when an attacker can manipulate the DNS lookup process and direct users to a fraudulent website that looks identical to the legitimate site. It is achieved by intercepting DNS queries and responding with fake records modified to redirect the user elsewhere. DNSSEC prevents this attack by providing a mechanism to verify the authenticity of DNS records.

Another issue is DNS spoofing, which is similar to DNS cache poisoning but occurs when an attacker can inject false DNS records into the cache of a DNS resolver. It can allow the attacker to redirect traffic to malicious servers and intercept user communication. DNSSEC mitigates this by adding a layer of validation to the DNS records returned to the resolver.

Furthermore, DNSSEC can prevent man-in-the-middle (MITM) attacks by ensuring that the DNS records are authentic and have not been tampered with during transit. MITM, explained in Part-2 of this series, is when an attacker intercepts communication between the client and the server and alters the data. DNSSEC can prevent this by adding digital signatures to the DNS records.

Conclusion

Why several websites do not implement this feature may range from lack of awareness, cost factor, and risk of breakage to a complex setup.  But, the adoption of DNSSEC seems essential for ensuring the security and integrity of the DNS. 

Securing Public website domain - Part 2 - Implementing HSTS

Most of the time, the HTTP to HTTPS redirection for a website happens at the DNS, Edge, or Application layer. So by typing the naked domain (non-www) of the website, there is still a vulnerability between the user’s browser and these layers. The browser does not have the intelligence to redirect the URL to HTTPS. 

SSL ensures an encrypted connection between the browser and the website. HSTS forces web browsers to become intelligent and use an encrypted HTTPS connection at the Browser layer.

The first thing to understand is what kind of vulnerabilities are present if HSTS (HTTP Strict Transport Security) is not implemented. These are very fundamental and similar to vulnerabilities without HTTPS implemented.

Vulnerabilities without HSTS

a) Man in the Middle attack is when attackers can intercept traffic between a user's browser and the website and manipulate the connection to use an unencrypted HTTP protocol instead of a secure HTTPS protocol. This way, attackers can read or modify the content of the communication, leading to potential data breaches, session hijacking, or phishing attacks.

b) Cookie hijacking: Without HSTS, attackers can intercept or tamper with session cookies sent over an unencrypted HTTP connection. This way, attackers gain access to user accounts and steal sensitive information, such as personal data or financial details.

c) SSL stripping: Attackers can use SSL stripping attacks to devaluate the communication from HTTPS to HTTP and intercept sensitive data sent over an insecure connection. This technique is often combined with phishing attacks, where users are redirected to fake websites designed to steal login credentials or other personal information.

d) DNS hijacking: Attackers can perform DNS hijacking attacks to redirect users to a malicious server instead of the intended website. It allows the attacker to intercept and manipulate the communication between the user's browser and the fake website, leading to potential data theft or malware infection.

e) SSL certificate fraud: Without HSTS, attackers can use fraudulent SSL certificates to impersonate a legitimate website and deceive users into sharing sensitive information. It is an issue when users are not aware of the legitimate website's SSL certificate or security indicators, as they may unknowingly trust a fraudulent certificate.

Implementing HSTS

To implement HSTS, the response header just needs to be sent as part of the website's HTTP responses. The header should include the HSTS policy, which specifies how long browsers should remember to use HTTPS instead of HTTP when communicating with the website. 

A simple example of a code snippet that needs to be added to the header is as below: -

HTTP-Strict-Transport-Security: max-age=31536000; includeSubDomains

The max-age parameter specifies the number of seconds that the HSTS policy will be in effect. In this case, it is set to one year (31536000 seconds). The includeSubDomains parameter tells the browser to apply the HSTS policy to all subdomains of the website as well.

Once you've added the response header to the website's HTTP responses, any time a user visits the site, their browser will remember to use HTTPS instead of HTTP for a specified period of time, 1 year as per the above example

In summary, without HSTS, websites are vulnerable to a wide range of attacks that can lead to data breaches, identity theft, and other serious consequences. Implementing HSTS is the first crucial step in ensuring the security and privacy of website users.

Securing your public-facing website domain - Part 1

One of the unknown facts about a website or domain is how it implements proper SSL standards, leaving it insufficiently secure. Casually browsing through free online tools like https://www.ssllabs.com/ssltest/, and https://www.internet.nl/ made me realize how outdated we were from the realities of modern website security and privacy. 

Having the website as SSL does provide a secure layer that provides encryption between the web server and the browsers. However, we need to stay updated to keep us away from newer vulnerabilities.

The result of the free online tool gave our website a RED rating, and I had to take the entire report and address each item. Below are all the vulnerabilities that we started and eventually addressed. I will go through each of them in detail in subsequent posts.

1. Implement HTTP Strict Transport Security (HSTS) 

2. Implement Domain Name System Security Extensions (DNSSEC) 

3. Avoid mixed content: Ensure that all resources on your website, including images, scripts, and stylesheets, are served over HTTPS. Avoid including content from non-HTTPS sources.

4. Implement secure cookie settings: Use the Secure and HttpOnly flags on cookies to ensure that they are only transmitted over HTTPS and cannot be accessed by malicious scripts.

5. Use security headers: Implement security headers, such as Content Security Policy (CSP) and X-Frame-Options, X-Content-Type-Options, and Referer-Policy to protect against cross-site scripting (XSS) and clickjacking attacks.

6. Ensure websites have the latest TLS version enabled. Also, all old ciphers that are not supported are deleted.

7. Proper redirection from HTTP to HTTPS on the same domain in both of www. as well as for naked domains.