I sometimes find it amusing that the same high-level issues we face when addressing security now are the same as when I first started security work almost two decades ago. The tools may have changed. The people may have changed. The methods may have changed. The core problem and approach have not really changed.
Let's first define Enterprise Architecture. When done right Enterprise Architecture is a body of work that helps to connect business outcomes to the complex technical landscape and decisions that need to be made to deliver those outcomes. Enterprise Architecture helps to bridge the strategic gap between business planning and the detail work needed to build the supporting technology. That connection normally falls apart because there is a significant abstraction between the business function and the way that you have to conceptually break that function down in order to automate and accelerate it using technology. The people that you have working on the technology tend to understand the technology really well. The people that you have running your business functions tend to understand the business really well.
"A good Enterprise Architecture practice should be working at a level where it is involved in the development of the business plan and outcomes"
The security related take away from that is that good Enterprise Architecture will involve a deep understanding of the business outcomes. More specifically it will involve a deep understanding of the tradeoffs that leadership is willing to make to pursue those outcomes. How much are they willing to invest? Which risks are they willing to take to get there? How quickly do they want it? It is that insight that helps to drive great security solutions.
Let's take a look at a healthy security apparatus and see how it relates to what I just talked about. Properly implemented security is about right-sizing security measures in order to sufficiently mitigate the amount of risk that an organization is willing to engage in. There is an interesting tension (at least in my opinion) between complete security and easy business operations. The reality is that a good security approach lies somewhere in the middle of those extremes and that placement depends entirely on the amount of risk that is acceptable to business leaders.
A good analogy I like to use is the somewhat more established practice of retail organizations establishing an acceptable amount of shrink and fraud in their operations. At some point, the returns on investment for mitigating those types of threats becomes so cost prohibitive that the organization finds an acceptable balance. They don't want to completely ignore it, but they also don't want to invest all of their potential profits into controlling shrink and fraud. Over time a balance is struck.
In the same way, a good security team should be fed with enough information about the organization's appetite for risk so that the security technologists can design an appropriate response to that need. When done right the security organization should never be dictating the security response based on their own risk appetite, or even worse "gut feeling." This is where Enterprise Architecture can really serve the right-sizing of a security response. As Enterprise Architecture is assisting with the articulation of business outcomes, it is usually fairly easy to attach information about the security risk appetite. That will feed into the security decisions and tradeoffs that need to be made in solution design. More importantly, that will also help control the costs of the security approach to ensure that you're investing just enough to get as much risk mitigation as you need.
I personally am a huge proponent of risk methodologies that go far beyond the simple 5 point scale of impact x probability and instead work to categorize risk in financial terms because that is far more tangible to business decision makers. What I have found is far more valuable is categorizing risk in terms that match those being considered during the business' strategic planning. When the business is thinking through future plans, it is common to see some kind of matrix (frequently a SWOT analysis) showing business benefit versus the possible risks. A good security focused Enterprise Architect should be able to articulate the security risk in those terms and drive a discussion around the amount of information risk the business is willing to assume in order to achieve their outcome right along with all of the other information they need to gather and drive decisions on.
If that question is addressed then all of the subsequent work show flow easily. At the holistic level, there are standards frameworks like ISO2700x, NIST 800 series or COBIT which can help design, implementation, and operations figure out what security controls they need to address. Peer groups, vendors and technology forums can assist with the technical aspects. The understanding of the organization's risk appetite is what helps the specialists working on those designs size those controls correctly to enable the business enough while mitigating as much risk as necessary.
A good Enterprise Architecture practice should be working at a level where it is involved in the development of the business plan and outcomes. It should be able to help drive decisions on those things that will cause tension later on during technical design, such as the amount of acceptable risk that a solution can have.
Organizational risk appetite is the key information that will drive a measured and reasonable approach to security throughout the development of designs. As I mentioned in the beginning, that is the question that has plagued good security design as long as I have been involved in security. There is no better group than your Enterprise Architecture team to make sure that it is answered as part of their routine value delivery.