Security Analysis

This transition from “trust but verify” to “never trust and always verify” is a completely new way of thinking about the architecture of cybersecurity. At the heart of this change is the role of the Business Analyst (BA), who, given their role, bridges the gap between business requirements and technical implementation, making them indispensable in developing and deploying effective Zero Trust strategies. 

Striking a balance between usability and security is a challenging yet crucial responsibility for business analysts, demanding a blend of technical expertise, empathy, and strategic insight. By comprehending trade-offs, catering to stakeholder requirements, and adopting proactive measures, business analysts can develop systems that are both user-friendly and robust. As technologies such as AI and IoT progress, maintaining this equilibrium becomes increasingly vital, with AI-powered anomaly detection tools offering innovative ways to bolster security without compromising on usability. Successful business analysts will view this not as a zero-sum situation but as a chance to create systems that promote business success in a secure and accessible digital environment.

Emerging opportunities and responsibilities are presented to business analysts (BAs), offering a chance to bridge the business needs, influence technical design, and provide governance requirements. This further enables the BAs to define, validate, and guide in the process of changing to the adaptive access control.

In today’s hyper-connected world, information security is no longer just the domain of IT specialists and cybersecurity professionals. As organizations face an ever-evolving landscape of cyber threats, the role of the Business Analyst (BA) has become increasingly vital in safeguarding sensitive data, ensuring regulatory compliance, and embedding security into the very fabric of business operations. Business Analysts are uniquely positioned at the intersection of business objectives and technical solutions, making them indispensable allies in the fight to protect organizational assets.

This article discusses how the discovery process must shift from a merely functional exploration to one that includes a structured view of risk. By including security considerations in process mapping from the start, businesses may prevent the accumulation of security debt and design systems that are both robust and compliant.

Integrating least privilege into business analysis is critical for developing secure, well-governed systems. When role modeling is handled early, business analysts help reduce unnecessary access, reduce compliance gaps, and improve operational efficiency throughout the organization. Analysts can make substantial contributions to access governance throughout the system lifecycle by leveraging tools like CRUD matrices, role-function overlays, and access review templates. Access modeling, when it is used as part of core business analysis, improves audit readiness, enhances regulatory compliance, and reduces the risk of privilege misuse before it becomes a major issue.

Business analysts (BAs) are critical in ensuring that security issues are pegged into business processes as early as possible. One of the best methods in eliminating security risks is through threat modelling. It is one of the best strategies for reducing the risks associated during the undertaking of systems operations in a company.

By and large, threat modelling is an effective methodology that analysts can apply to address security risks within business processes. With this technique, BAs can work more effectively with security and development teams to ensure that processes are secure, compliant and well designed.

Imagine you have just led a successful incident response effort, restoring order after a critical cyberattack. Systems are back online, data is secured, and the team breathes a sigh of relief. But the question lingers-how do you know if your response was truly effective? This is where metrics and key performance indicators (KPIs) come in, and business analysts play a vital role in defining them. Metrics and KPIs help organizations assess how well they manage and mitigate cybersecurity incidents. For business analysts, identifying the right KPIs for incident response is essential not only for evaluating current processes but also for driving improvements. Let's explore how BAs can create a powerful set of KPIs to gauge incident response effectiveness and ultimately enhance business resilience.

With the massive shift to working from home we now see a plethora of tech companies flogging new employee surveillance tools. You can readily see their appeal to command-and-control thinkers. If you think, as they do, that managing employee activity is crucial, then to know who’s doing things and who’s taking the mickey is grist to their mill. But these tools will undermine performance and morale.

Think about it from the employee’s point of view. Your boss can see your emails, any documents you read or create, your appointments, who you talk to, and when; can listen to or read transcriptions of your calls. Your boss can see your computer screen, can monitor your internet use, the sites you visit and for how long. Your boss can even turn on your camera and watch you at work.

Personally, I believe the best approach to enterprise risk and security management (ERSM) is to rely on several open standards, most notably the ArchiMate standard for enterprise architecture modeling, as well as the Open FAIR standard for information risk management. More details are described in The Open Group’s white paper on modeling enterprise risk management and security.

 In this article we look at some quality attributes that are particularly vital to explore when specifying requirements for embedded systems projects. Quality attributes for embedded systems can be much more complex and intertwined than those for other applications. Business software is generally used in an office where there’s not much variance in the environment. In contrast, the operating environment for embedded systems could involve temperature extremes, vibration, shock, and other factors that dictate specific quality considerations.

When security requirements are considered at all during the system life cycle, they tend to be general lists of security features such as password protection, firewalls, virus detection tools, and the like. These are, in fact, not security requirements at all but rather implementation mechanisms that are intended to satisfy unstated requirements, such as authenticated access. As a result, security requirements that are specific to the system and that provide for protection of essential services and assets are often neglected. In addition, the attacker perspective is not considered, with the result that security requirements, when they exist, are likely to be incomplete. We believe that a systematic approach to security requirements engineering will help to avoid the problem of generic lists of features and to take into account the attacker perspective. Several approaches to security requirements engineering are described here and references are provided for additional material that can help you ensure that your products effectively meet security requirements.

In writing a business requirements document (BRD), the business analyst needs to document who can access the solution (assuming software) and what data can be created, updated, read, and deleted (CRUD). In other words, a security model that a security analyst can build access profiles with the appropriate privileges.  This article provides the business analyst a method for documenting a security model in the BRD based on information extracted from Use Case and Class models

The reason is simple, anyone involved in Information Security needs a detailed understanding around how things work; where the dependencies are, the inner workings of programs and applications, who has administrative control over sensitive information, where the information is being stored, and how clients and programs interact with the data.

Performing threat risk assessments (TRA) involves an intimate understanding of a solution or service. This means everything from the pretty UI right down to the bits of code your development team scribed to make it look that way. 

The only way to understand these systems is via detailed communication with stakeholders, architects, business analysts, systems and network administrators, executives, clients and their technical resources, board members, vendors, ISPs, and the list goes on.

Here we are, the end of another year, and the question I ask always is, what have we learned?

If we are not learning something, be it from a success or a failure, or something in-between, then how can we move forward?

Information security is something that needs to continuously improve and refine itself, otherwise it will fall behind the curve of those that choose a different avenue to your beloved data store.

A tool that information security practitioners often use, especially after a security incident like a virus outbreak or full out attack, is holding a “Lessons Learned” meeting.

The core concept is to be able to take something away for the incident, no matter how big or small, so that the next encounter of a similar kind does not have the same result as the first.