In this video, you will learn to describe why comprehensive cybersecurity architecture can be very complex to implement in reality. Translation of simple business requirements into technical specifications and deployment decisions can be very difficult. The protection mechanism itself is subject to attack. Protectors have to be right all the time. Attackers only have to be right once. An additional challenge to the security ecosphere has to do with the complexity of the solutions. So the first point about security not as simple as it seems is a huge understatement. Our customers frequently have very simple requirements. For example, one requirement might be that all users will authenticate to the enterprise. Sounds easy enough, but when we start looking at the implementation and the engineering behind a comprehensive access control system, role-based access control, or perhaps attribute-based access control, and privileged users, and archiving, the solution gets very complicated, even though it's got a very simple high level requirement. You see this all the time. It is part of the security professionals job description to take these somewhat simple requirements and being able to decompose them into accomplishable or achievable modules for that. An additional complexity for security architecture is the fact that the solution itself could be attacked. There's the principle of the security enforcement point or SEP. The security enforcement point is a technical implementation of a business policy. For example, as we were just talking about access control, is that the business security requirement is, all users will sign on to the system. The technical implementation of that might be for strong authentication or something you know, something you have, the tracking of privileged or system administrators. Somebody can change a security policy. So we have technologies, we have software, and we have hardware, we have firmware that implements or delivers the technical solution to these business security requirements. That's the definition with security enforcement point. Well, the similar point is that, the adversaries, the attackers know that to get to the information that they are after, that they need to defeat the protection mechanisms. They need to breach the moat, scale the wall, break the gate, right? So these enforcement structures are just as much a target as the actual data itself. So level of complexity that's not found in other technical disciplines are then we very much need to be aware of within the security world. As we pointed out the protection of the security enforcement structure, not can but will complicate the solutions. Because you've got this additional layer of protection, in terms of protecting the protection mechanisms. Some additional challenges that face the security professional has to do with our security architecture decisions, right? So we'll talk about logical architectures that describe more what we're doing as opposed to how we're doing it. So then we start getting into the topology of this, where these enforcement mechanisms will be placed within the architecture. For example, generally, we want access control technologies closer to the parameter, closer to the DMZ. However, some insecurity, some Net flow sensors may be more towards the center of the enterprise. So there's some architectural decisions, there's trade space studies, there's trade offs, there's risks, and benefits for these decisions. It takes a seasoned architect to be able to help define where these deployment decisions will place these technologies. Second point, we'll talk about key management being very difficult. So when we talk about key management, we're talking about cryptographic keys. You remember the earlier diagram with Alice and Bob. Alice would encrypt or protect her message before putting it onto the transmission channel. A cryptographic system uses a key, and there's a corresponding key in Bob's domain for him to decrypt that message. So the key management of the creation of those keys and the distribution of those keys, which we will look at little later, is a very complicated solution. So something to keep aware of would that. Then there's this larger principle that we as the defenders need to do, have to be right all the time. So the dynamic attacks that are out there, that change every day, every week, right? The security architecture needs to be flexible enough to be able to protect against those attacks, so 100 percent of the time. So people, places, things, time, and money, all of which are in quite in terms of having a dynamic security architecture that protects the information, protects the enforcement points against these constantly changing elements. So they have to be right all the time. Security architecture that protects 90 percent of the time is not going to be well embraced by any business. However, the attackers really only need to be right once in order to succeed. So you see the disparity, the imbalance, the disproportionality of success between attackers and protectors. The business line generally considers security unnecessarily either. There's principle about the seat belt philosophy. A seat belt costs about $200 to put into a vehicle, but that one-half second before a serious automobile accident, that seat belt is worth more than a million dollars. Security constructs are exactly the same thing. The security of the business lines frequently considered to be security in the way it is incumbent upon us as security professionals, to ensure that the security constructs are actually enabled, right? So that we make it easier to conduct business in a complex world. Our last set of challenges and of course, these are fairly high level, but can be decomposed into additional challenges. Talk about the constant effort being afterthought towards security, and that security is frequently viewed as a obstacle. So somewhat in reverse order, that the business lines within the enterprise frequently view security as an obstacle, as a barrier. This is something that is necessarily evil, and we need to operate and just do our best to get sometimes to. That encourages, by the way, people to try to do end runs around security. Security professionals responsibility is to make security an enabler, all right? So make it a positive value. This helps us do business in a very complex and very threatening world. We'll talk more about that a little bit later. So why is security sometimes viewed as an obstacle? Is the fact that it's not integrated early into the development life cycle, system life cycle development for the project. So we look at life cycle models such as our work model or iterative engineering, and you don't see security in the functional definition. So the security professional needs to convince the project leaders that this is at least expensive way to integrate security into the approach is to be included early. So that way you'll have application developers, infrastructure, our security people there, test engineers, Q&A. All of those have a place fairly early in table. The top point about security architecture is requiring constant effort speaks to the dynamic nature of our task, that the adversaries are constantly introducing new attack profiles, new vulnerabilities are released from software manufacturers that are turned into exploits, just the war changes and it changes every week. So constantly, our defense mechanisms, our security architectures also need to be very mobile, very agile to adapt and to change to these changing attacks. Otherwise, we will be very much like we go back in the 1990s with static, castle, moat drawbridge type of security architectures.
