Enterprise Architecture and Security
Taking a quick break from our series on “How do I become an Enterprise Architect”, this post focuses on a topic of increasing importance, not just for EA’s, but for business and IT executives everywhere. In fact, I would go one step further and say “Security is everyone’s concern”.
So what should an Enterprise Architect be thinking about in regard to security? The reality is that there are many aspects to ensuring an organisation has a healthy security posture, but it’s important to understand what we are referring to when we say security. Primarily, we are referring to Information Security, although in some organisations, the remit may be wider. For this article, we’ll focus on Information Security, which often has a much broader set of concerns than many people realise. Here are just some of the things to contemplate:
Risk
Do you have an understanding of the risks associated with security of your organisation’s data? Are there financial penalties from your industry’s regulator? What about reputational risk?
Ease of access and use
There is always a trade-off between timely access to information for legitimate business purposes, and the need to secure it from unauthorised access. Knowing where to draw the line is something that takes time to understand, and is not the responsibility of the EA. They should be working with the organisation’s Legal, Risk & Compliance teams, and relate this need for access to the legislative obligations of the organisation.
IAM
How do you effectively manage access to systems and information? Do you have centralised control, federated identities, and effective tools for managing the information. There are a few IDaaS solutions available in the marketplace that can help managing this crucial part of your organisation’s security.
Of course, that’s employee/contractor access to information. What about your customers and how they access information. Do you leverage their Social Media authentication? Do you have effective standards in place regarding password complexity?
What other policies do you have in place for both internal and external access to systems?
Compliance
Most organisations will have a regulatory compliance obligation that they must work within (probably more than one!). That will vary depending on the geographical local your company is in, but often relates to subjects such as:
- Data Sovereignty
- Privacy
- Payment Card Information
- Retention
An EA must have a strong understanding of the obligations unique to their company’s industry, as well as those that are more generic.
IoT
With the increased adoption of IoT based technology, a whole new set of security concerns are emerging. If your organisation is looking to leverage this enormous (and potentially valuable) source of information, the EA must ensure that security is foremost in conversations about its introduction.
B2B integration
When B2B integration is mentioned, most people will think of some form of defined interface, be it a realtime approach through WebServices and the like, or via batch interfaces using protocols such as SFTP. This is important, but is only part of the picture. You may have a supply chain that requires sharing information, including sensitive data about your customers. In establishing these business relationships, your organisation should concern itself with the approach to security being taken by your partner(s). Here’s an example:
You company sells a range of spare parts, and you have an eCommerce platform to enable online ordering. You have an outsourced delivery service provider, with whom you share the name and delivery address of your customer. Are they storing that data securely? How long do they retain the data after the package has been delivered? Where are their systems storing that data (i.e. are there Data Sovereignty issues)?
This is where a broader definition of an “enterprise” can be useful. The term does not need to be constrained to a single legal entity. It is often beneficial to think about an enterprise in terms of the company and its relationships with other organisations, and even the community to which it belongs.
Physical Security
A lot of focus is placed on the secure transmission and storage of information, or what might be described as Electronic Security, but one area that should not be overlooked is Physical Security. Most people are familiar with the standard IT environment, where a special room houses the most important of the company’s infrastructure. Typically that is a space only accessible to a small number of Operations Staff. This is just one aspect of the physical security requirements needed to protect your company’s data. Here are some of the areas an EA should be aware of, despite not having direct responsibility:
- Data Centres
If you’re utilising an external provider for one or more of your Data Centres, what standards do those providers adhere to. Standards such as PCI and SSAE 16 are commonly used as guidelines to ensure that Data Centre providers can ensure the security of your information.
- Removable storage
How easy is it for employees or other onsite personnel to access and remove data using hardware such as USB drives or portable HDD’s? What policies are in place to ensure that this access is not abused? Do you have effective processes (or contracts) in place to ensure that data being carried on these devices is destroyed when that person leaves your organisation?
- Mobile devices
I’m sure many of you are familiar with the risks associated with unprotected or stolen mobile devices. In the past, this has been mainly constrained to corporate emails and an employee’s calendar. That is set to change dramatically with increased access to corporate systems and data on a range of devices.
Consideration should be given to what type of data might be accessible and stored on mobile devices. Access to the device should also be secured using features such as PIN codes, passwords or biometric security devices (e.g. fingerprint scanners), as well as Two-Factor Authentication.
Consideration should also be given to the use of MDM (Mobile Device Management) platforms. They give an organisation the ability to locate, lock-down and remote-wipe devices, which can be very important when one goes missing. I’m sure you’ve all heard of the phones, tablets and laptops that have been left behind in the back seat of a cab. These things happen, and you should be prepared.
- Backup data
Often overlooked when implementing new systems is how the data will be backed-up and recovered in the event of a disaster. With the back-up process comes a multitude of copies of your data, which must be secured, and retained according to both internal policy, and legislative obligations.
Patching
Do you have procedures and processes in place to ensure all of your systems and infrastructure have up to date software or firmware? Exploits are discovered every day, and patches are released by vendors just as frequently. It would be a difficult conversation with senior management if your data was stolen using a known exploit!
Software development
When designing new software, are your Solution Architects, Application Architects and Senior Designers cognisant of the need to include security as a core element? Do they use resources such as OWASP to ensure that common exploits are unable to be used to gain access to systems, data and networks?
Non-production environments
Another item that is often overlooked within IT environments is the replication of data across Non-Production Environments (NPE’s). Is data masked or de-identified when copies are made? Is data in these “lower” environments protected in the same way as your production data? Typically this is not possible due to the processes that require access to the data (e.g. User Acceptance Testing, Training, etc.), so policy and masking of data is often the only choices available.
Data Principles
The use of a robust and visible set of principles will help drive decisions around protecting data and access to systems. Your Solution Architects should enforce these principles as part of their designs, and Data Security should be very high on that list.
Non-functional requirements
Another way of reinforcing the importance of security is through an effective approach to gathering and documenting Non-Functional Requirements (NFR’s). I often see this very important aspect of requirements gathering being overlooked, particularly because they tend to be of a technical nature, and the people responsible for documenting requirements (e.g. Business Analysts) have not come from a technical background. The EA can help here by ensuring that checklists are made available, and that education programs are provided that highlight the importance of security and other NFR’s.
Of course, there are many more aspects of ensuring data is secure, but hopefully the information above highlights three things. Firstly, there are many things to be considered to ensure security is implemented effectively.
Secondly, the EA needs to be aware of all of these things, but it is a range of other people that are responsible for implementing many of them. This requires the development of strong relationships with others in the IT function, particularly those in development, operational and infrastructure focused roles.
And thirdly, there are many aspects of securing your company’s data that are not part of the technology landscape. Collusion, a lack of effective policy enforcement and plain old forgetfulness (remember the phone left in the back of a cab) are things that can circumvent even the best intent. Security really is everyone’s business, and it needs to be at the forefront of people’s minds.
Have your say!
What do you think? Did we miss something important? Please join in the conversation by responding below, or by emailing us at [email protected]. We also want to know the subjects that are causing you professional pain. Please email your questions, and we’ll select one for a future advice column. The EA Practice Advisory Team is here to help.
