Security Architects and Engineering team

Note: All views in this article are my personal and team structure differs upon organization size, infosec team size, and business priorities.

The Security Architecture and Engineering team (SAET) plays a crucial role within the Information Security department of an organization. As the digital landscape becomes increasingly complex and threats more sophisticated, this specialized team is responsible for designing, implementing, and maintaining robust security solutions to protect the organization’s critical assets.

The team consists of skilled professionals with deep expertise in security architecture, engineering principles, and security best practices. They work closely with other teams within the Information Security department, such as the Security Operations Center (SOC), Incident Response team, and Risk Management team, as well as external stakeholders like IT Service and Operations teams, to ensure a holistic and coordinated approach to security.

The SAET’s responsibilities encompass a wide range of activities. They assess the organization’s existing security posture and identify vulnerabilities and weaknesses in the infrastructure and any visibility gaps in security. Based on these assessments, they develop and implement security controls, define policies on them, and establish procedures to mitigate risks effectively.

While the Security Engineering team focuses on the design and implementation of these tools, the Security Administrators are responsible for their day-to-day operations, monitoring, and maintenance.

Once the Security Engineering team has designed and deployed a security solution, it is handed over to the Security Administrators for the operational phase. This handover involves sharing knowledge, documentation, and providing necessary training to the Security Administrators to ensure they have a thorough understanding of the implemented solution.

In addition to their preventive measures, the SAET also actively monitors emerging security tools and trends. This team also stay up to date with the latest technologies, industry standards, and regulatory requirements to continuously improve the organization’s security posture. This includes evaluating new security tools and technologies and making recommendations on their implementation to enhance the overall security infrastructure.

Sub Teams:

Similar to Security Administrators, the SAET members are also divided based on their expertise in specific domains of security. This division allows the team to effectively address various aspects of security architecture and engineering, leveraging the specialized knowledge and skills of each team member.

If you need a refresher, you can read more about these domains, tools, and roles in the previous blog in the series.

Note: You might not see Cloud Security and SIEM Administrators in the above sub-team diagram as these tech stacks aren’t often changed as frequently and don’t require intervention from SAET once implemented.

Security Tool Accuqisition Process

Imagine the team has to get a new EDR solution, as the current tool license and the legal contract is expiring. Whats the process for this transition to happen?

When a requirement comes in, the Security Architect and Engineering team go through certain steps, which ensure the tool meets the requirements while balancing the cost.

1. Invoke Engineering: When requirements come in, either from the internal InfoSec team or as an outcome of a security audit or gap assessment, the team initiates a project to fulfill the requirement. This includes defining a plan for the project, defining milestones and timelines.
2. Requirement Gathering: Now it's time to come and define the exact requirements which are supposed to be met as an outcome of the project/tool. This happens with the help of internal stakeholders, including the SOC team, the GRC team, and Security Administrators as well as external stakeholders like IT service and operations teams.
3. Proof of Concept (POC) and Evaluation: Once the requirements are there, SAET will initiate a conversation with various vendors for POC (it means short test of capabilities and features on small scale), design criteria for evaluation, and run a short POC with a temporary license to see if it meets the evaluation criteria.
4. Technical specifications: Once the POC is complete, its time to define exact technical specifications and break down the requirements into various buckets like tool capability (eg: for an EDR, the capability to run PowerShell script/Batch script on a remote endpoint that is reporting to the console), Administrator capabilities (eg: again for EDR, tool should support the creation of dynamic host groups basis criteria such as, but not limited to: Hostname pattern, Operating System, Active Directory Groups, etc), Authentication capabilities (eg: integration with Active Directory and Cloud SSO platforms), etc.
5. Request for Proposal (RFP) Creation: All the technical specifications are incorporated into a Request for Proposal (RFP) document. It is a formal document that a organization uses to solicit bids from vendors or service providers when they are seeking to procure goods, services, or solutions. It serves as a comprehensive outline of the organization’s requirements, expectations, and evaluation criteria for the project or procurement process. The RFP document serves as a key communication tool between the organization and potential vendors or service providers. It provides a structured framework for vendors to understand the organization’s requirements and submit detailed proposals that address those requirements. The document plays a crucial role in ensuring transparency, fairness, and accountability throughout the procurement process.
6. Inviting Vendors: Once RFP is published, vendors are invited for bidding. The RFP isn’t available to the public, however, a notice is posted to the company’s website through which vendors can be notified or it can be a private RFP, and pre-selected vendors are invited to participate in it. Basis the RFP and defined criteria, vendors present their solutions to the evaluation committee. During this time, vendors and the committee also ask any questions back where clarification is needed to understand the scope of the project, and thus to propose the exact cost.
7. Vendors Evaluation: Based on the evaluation criteria, narrow down the list of potential vendors and security tools to a manageable number for further assessment.
8. Bid Placement: The shortlisted vendors then place their bid as to how much the expected cost is for the project and the breakdown of the cost, license, training, and support offered by them.
9. Reverse Auction: An independent internal committee then evaluates the proposals, and sees if it can go for reverse auction. And if there is a scope for a price reduction, a reverse auction is initiated between all the vendors who shared proposals for competitive pricing.
10. Initial Onboarding: Once the vendor is finalized, legal documents are signed and a payment order is released, and the initial meetings are then setup and conducted between the vendor and the implementation team (members of SAET).
11. Implementation Support: Here the vendor supports the SAET members to design, architect, and implement the solution into the organization in accordance with best practices while meeting the scope of the project. Any issues that arise during this time are actively handled by the vendor (usually the customer success manager and technical lead). This step also includes the integration of the new tool into SIEM and creating detection use cases for SOC to monitor.
12. Post-Implementation Testing: Once the solution is deployed, one final test is done to ensure the tool is functioning and meeting the requirements. A formal sign-off is given to the vendor about the deployment of the tool, and thus any further support required will be handled via tickets.
13. Handover: Once the Security Engineering team has designed and deployed a security solution, it is handed over to the Security Administrators for the operational phase. This handover involves sharing knowledge, and documentation, and providing necessary training to the Security Administrators to ensure they have a thorough understanding of the implemented solution.

InfoSec Overall

So far, you have learned about SOC, Security Administrators and Security Architect and Engineering team. These are probable avenues (but not limited to) where SAET interacts with SOC and Security Administrators.

1. As discussed earlier, SAET handover the newly implemented tool to Security Administrators for maintenance and running the tool.
2. Security Administrators interact back with SAET about new learnings and where the tool is lagging and isn’t working as per earlier defined expectations, so SAET can improve their evaluation criteria and raise the concerns back to the vendor.
3. The SOC and the Security Architecture and Engineering team maintain an ongoing feedback loop and knowledge sharing process. The SOC provides feedback to the Security Architecture and Engineering team on the effectiveness of implemented security controls, detection mechanisms, and incident response procedures. This feedback helps the Security Architecture and Engineering team fine-tune their designs and continuously improve the security infrastructure. Similarly, the Security Architecture and Engineering team shares knowledge about emerging threats, new technologies, and best practices with the SOC to enhance their incident detection and response capabilities.

Conclusion:

The Security Architecture and Engineering team plays a vital role within the Information Security department by designing, implementing, and maintaining a secure infrastructure to protect an organization’s critical assets. Their expertise in security architecture and engineering principles enables them to collaborate with other teams, such as SOC and Security Administrators, to proactively detect and respond to threats while continuously improving the organization’s security posture.

In the next and final series of the blog, I will be covering the role of the Governance, Risk, and Compliance team in Information Security and how they lay the foundation for any InfoSec Program of the Business.

Link to next part: https://medium.com/@inishantgrover/information-security-governance-risk-and-compliance-team-5b7222f12f21

Video Series Link: https://www.youtube.com/playlist?list=PLYvPOAFzOkSsGlrW74f-2351WW9Sh7S3u

Link to previous part: https://medium.com/@inishantgrover/role-of-security-administrators-15939914907c