I’ve been working as a security architect specializing in cyber, Appsec and cloud for a number of years and I have to work with different security professionals including security engineers. The difference in what I do compared to what a security engineer does is markedly different and it’s important for anyone considering a career in security to understand these differences.
So, what’s the difference between a security architect and security engineer? As a general rule, a security architect is the person who decides how security is done, whilst the security engineer is the one who implements security on behalf of the security architect. If a security architect decides a particular security tool is needed after their analysis, then the security engineer will be tasked with installing and configuring the security tool.
Security architects tend to be less hands-on technically and more focused on the decision making process, taking in information and analysis from various sources including security best practice guidelines, security frameworks, security requirements, regulatory requirements, legal requirements to threat analysis to determine the best security approach.
What the security architect decides especially if it’s something that needs implementing, for example a security tool, updates to threat intelligence to fixes for security issues in the wild, these will generally need the assistance of the security engineer to do the implementation part. The security architect will not be generally involved in the hands-on technical part of any implementation.
In my role as a security architect, I may decide on protection being required to make sure internet traffic to my employer’s websites is inspected to see if there is anything malicious, like SQL injections where a specially crafted database language query using the SQL language is constructed by an attacker or hacker.
These specially crafted malicious SQL statements can lead to a breach of the database when successfully carried out, allowing hackers and attackers to steal data, like credit card numbers, personal details to passwords.
I decide to protect against these types of attacks, protection is required using a Web Application Firewall (WAF). I won’t end up installing the Web Application Firewall, as I have no idea how to install and configure one. Instead this will be delegated to someone who is more experienced in dealing with this, like a security engineer. I will discuss some of the rule sets I would like to be implemented, making sure the minimum OWASP Top 10 rules are covered as these include SQL injection.
In my role as a security architect when I’m reviewing a new project to make security decisions, I look at the risks and potential threats based on the overall security strategy, the security policies, security standards to legal and regulatory requirements to come up with a set of appropriate security requirements tailored to the project.
So, if the project is involved with developing a new application then I need to review the security strategy around application development as well as the application security standards including any relevant security policies, like passwords, encryption and so on, to regulatory requirements like Payment Card Industry Data Security Standard (PCI-DSS) to come up with an informed set of security requirements for the project to work to.
The application security requirements could include protecting against a number of threats and attacks like SQL injection, which can be used against my employers databases to steal information. The application developers will need to adopt measures to protect against SQL injection type attacks, using some form of parameterized query construction to using an Object Relationship Mapper (ORM).
What does a Security Architect do?
Security architect roles generally involves working to define security strategy, this can be elements of this or depending on their security architect role, large parts of the overall security strategy. Security architects will also be involved in security assessments and in some cases creating patterns for security projects, solutions and services.
Define security strategy
Security architects especially enterprise security architects are generally involved in defining security strategy. Security strategy is deciding how an organization deals with it’s security needs from a people, process and technology aspect.
Where there are people involved could include the various roles involved in security from architects, engineers to analysts. The process involved could be how security incidents are dealt with, along with the technology used to make this all happen.
My involvement in security strategy ranges from assessing security tooling and defining what security tools my employer should be using strategically and if these are not available to the organization (maybe they are still being procured) then tactical alternatives that can be used in the meantime.
Security Assessments
Security architects are involved in assessing their organization from a top down perspective where a periodic assessment is made to individual project or even solution assessments. These assessments involve taking the security policies and security standards and applying these to see if there are any gaps leading to non-compliance.
Any gaps would then be assessed as a risk and those risks which are deemed to be high enough to affect the organizations security posture will then need to be either mitigated, that is fixed or reduced or taken as they are and accepted by the organization.
Creating security patterns
A security architect will also create patterns, these are blueprints for security services, products and solutions. These patterns will generally be technology agnostic and at a high level, then using the approved strategic technology options available, as defined by the organizations security strategy the appropriate technology will be used.
So, a pattern could include a Web Application Firewall (WAF) and when this pattern is used in Amazons’ AWS cloud, the AWS WAF is used or if it’s Microsoft’s Azure cloud, the Azure WAF is used, or if it’s in an organizations data center then a F5 WAF is used. The pattern only highlights the type of technology to be used and not the exact technology product or solution to be used.
I get involved in DevSecOps, which is involved in automated code deployment where a developer writes code for an application and this code is then submitted through a number of automated checks (continuous integration). Once these checks have been successfully passed, the code can move onto be deployed (continuous deployment). This whole continuous integration (CI) and continuous deployment (CD) is known as a CI/CD pipeline.
I will define the pattern that is a blueprint including how security affects the CI/CD pipeline but also the developer who is submitting their code into this pipeline. This includes the security tooling to be used, like Static Application Security Testing (SAST) to check for security issues in the developers code, Software Composition Analysis (SCA) to check the libraries (third party programs) used don’t have any vulnerabilities, Dynamic Application Security Testing (DAST) to do a mini penetration (PEN) test on the produced application at the end of the pipeline.
I will also look at the processes on how the developer’s code is checked to make sure it can be submitted into the CI/CD pipeline from the peer review, where senior coders check the code including reports from any security tooling used, like SAST integration into the coders integrated development environment (IDE) which checks the code they write for security issues.
This is part of a “shift left” strategy where the onus is on fixing more security issues at the coding end instead of later when it’s become an application and is being used. As fixing security issues when the code is an application being used, is prohibitively more expensive than when it’s just code at the developers end.
Designing Security Solutions
Some security architects will take the security patterns and design the security solution from this, that is the exact technology involved. So, with the DevSecOps pattern I talked about earlier, the security architect will look at where the DevSecOps pattern needs to be implemented including what technology to use as defined by the security strategy and the security processes required.
If the DevSecOps pattern is going to be used for a project that is based on the Amazon AWS cloud, the security architect will review their pattern and consider the use of AWS tools such as CodeGuru for the SAST element (if it’s approved for use by the security strategy) and any security tooling not available natively (that’s approved) looking at using approved technology like Veracode’s SCA to Veracode DAST tooling.
Defining Processes
Security architects will also create security processes, that is the way things are done, so if the security architect is involved in incident management, where an organization has to deal with threats and attacks. The security architect will look at what to do if an attack occurs, including the people, processes and technology involved.
The processes could be what to do when the attack is discovered, who needs to be involved to what checks need to be made such as making sure the attacker is still not present in the organizations systems to finding out what’s been taken, destroyed or added.
What does a security engineer do?
A security engineer is more involved in the hands on technical aspects of security, where they are involved in implementing security tools, fixing security issues, working in incidents, updating security issues like vulnerabilities to the configuration of security services.
Implementing Security Tools
Security tools are important technologies used by organizations to provide them with some protection against threats and attacks. The security engineer will be involved in installing and configuring security tooling including:
- Intrusion Detection Systems (IDS)
- Intrusions Prevention Systems (IPS)
- End Point Management (Antivirus)
- Data Loss Prevention (DLP)
- Web Application Firewalls (WAF)
- Anti Distributed Denial of Service (DDoS)
- Firewalls
These are just a small number of security tools involved and the scope of security tooling especially when cloud services like Amazon’s AWS, Microsoft’s Azure to Google’s Cloud Platform (GCP) is huge.
Break-Fix
Not everything runs to plan and when things stop working as expected they need to be fixed, especially if it’s security tooling or services. This is where the security engineer can become involved in providing a temporary fix or providing a permanent fix if one is available.
For example, the intrusion prevention system (IPS) stops working where as a smart firewall it stops inspecting the incoming traffic for malicious data. The security engineer could be involved in trying to find out why this is happening, may be the service used by this IPS that inspects data has stopped working and needs to be started.
Dealing with incidents
A lot of the time the security engineer will get called into the incident management meetings when a breach is likely, is happening or has already happened. The security engineer will be instructed to do certain things based on what the security analyst has discovered. This could include shutting down access, checking configurations to spinning up additional security tooling.
Updating
Technology is only as secure as the last time it was checked to make sure it’s secure, so if I checked a security tool being used today for any security issues like vulnerable components. Any resulting check that showed no vulnerabilities wouldn’t necessarily mean later today, tomorrow or even at the end of the week; the security tool was still secure without any vulnerable components.
Vulnerable components are being discovered all the time by white hackers and security testing teams around the world and this forms part of the threat intelligence organizations receive. A security tool with no vulnerabilities on one day could be vulnerable later the same day, the next, the next week to month or even year.
Once this vulnerability is known, a plan is required to update the vulnerable component with a non-vulnerable component. The actual implementation of the new non-vulnerable component will be done by the security engineer as part of a patching process.
An organization could have hundreds of computers running Microsoft windows ® operating systems and a severe vulnerability in this operating system is found. Once a plan of implementing a fix that is the patch is found, the security engineer will implement this using some form of tooling like Microsoft System Center Configuration Manager (SCCM).
Configuration
Security Engineers will be involved in configuring services, tools and products that are already implemented. These may not have been implemented by the organization themselves but instead the organization has brought in services especially cloud services.
If the organization uses Microsoft’s Azure Cloud service, then the security engineer could be involved in some of the security aspects like configuring the Azure Security Center for security reports like the Center for Internet Security (CIS) benchmarks to the Payment Card Industry Data Security Standard (PCI-DSS) benchmarks. These benchmarks check the cloud environment to see if the configuration of the cloud components like virtual machines to databases has been done securely.
Security Architect Misconceptions
Many people especially hirers like recruiters assume security architects are just someone who designs solutions and finding a security engineer who can not only install and configure but can also design is the way to go.
I deal with hundreds of hirers each year and around 9 out of 10 of them have no clue as to the difference between a security architect and a security engineer. Not only do they waste my time, but they also put the organizations they are hiring for at risk.
As it leads to the organization making themselves vulnerable to security risks, as the security engineer will design, install and configure what they seem appropriate and if they are very technically minded then they will focus more on technology to solve an organizations security problems.
Whilst a real security architect looks not only at the technology, but the people and processes involved, as well as the security strategy, regulatory requirements, legal requirements, security standards, security policies to security best practices to make an informed decision on security.
A Security architect is also the WHY person, asking people why they want to do something, like for example if they are designing a new data lake environment and have included putting real customer data in a test environment, a security architect will need to know why they have put real customer data in a test environment.
A security engineer will be the YES person only interested in delivering the security of a solution and will look at making sure the technology is sufficiently protecting the customer data. So in the data lake example above where there is real data in the test environment, they will most likely just look at the access controls to the firewall setups to make sure the customer data is protected. They will probably not even look at the organizations information security policy which could dictate that no real customer data can be put into test environments.
My aim as a security architect would be to know not only why a project wants to use real customer data in a test environment but also who has sanctioned this, as well as why they can’t use obfuscated (anonymized) data.
If it transpires, they can’t do what they need to do with fake data and need real data (especially if it’s building machine learning data models) then I need to look at the risk and who is prepared to accept the risk on behalf of the organization.
Generally in these situations the teams back down and agree to use fake data because I have done the due diligence in trying to find out the risks of doing so. I use a risk based approach in the way I look at security and many of the security engineers I work with don’t do this, they are just doers, who use their technical abilities to engineer solutions.
By using a ‘doer’ instead of a ‘thinker’, that is a security engineer instead of a security architect, an organization can put themselves at risk. This is why it’s paramount to use a security architect in the non-hands on technical work, where decisions need to be made and use a security architect to implement the outcomes of the decisions made by the security architect.
Check out my FREE guide – How to Get into Cyber Security for Beginners (5 Must Know Tips)
