Security was a concern at the outset of new development for DAKS (Digital Analogue Knowledge System). It is very difficult to go back and make software secure. Architecture plays a key role as well. This post goes into detail about architecture and practices to ensure we have a secure environment.
ISO 27001 Certification
The ISO 27001 certification certifies our Information Security Management System (ISMS) against the ISO 27001 requirements. The best way to summarize any such certification is to “Say what you do and do what you say.” That sounds so simple, but I have rarely seen it done. In most cases there is a large team writing extensive documentation. And meetings will result in statements such as, “We could do even better if we added this on!” I’ve seen documentation that, if one tried to do everything it said, would cause the company to go out of business because there was too much overhead.
We started developing DAKS in January 2015 and security was top of mind. When embarking on ISO 27001 certification we changed very few of our practices or implementations. It was really an exercise in documenting what we did. We have achieved the balance. Our actions match our words.
While C&C Reservoirs’ ISO 27001 certification is recent the security practices highlighted here have been in place for almost a decade.
Key Security Practices
Cloud Based
As mentioned in the post on the Development Environment we use cloud computing for everything but the developer computer. As a result, there is minimal work to maintain operating systems and firewalls. For example, I’ve not been on a corporate network for almost a decade. The only people that really need to be on a network are those that need to access office printers.
Azure DevOps
Azure DevOps provides a secure development environment for the team with minimal maintenance on our part.
Access Control
We utilize Entra ID (formerly Azure Active Directory) to control access to Azure DevOps for organic and consultant resources. Two factor authentication is required for all users. Only two users can control the Team Members.
Source Control
Git in Azure DevOps is used for version or source control. No passwords are stored there. In order to accomplish this, we use Azure Key Vault to store passwords that are protected by machine identities for all the services that require access to the Key Vault. That entails turning on the use of Identity for each App Service in Azure and then going to the Key Vault and granting that Identity access to the Key Vault.
Builds
CI (Continuous Integration) builds are used that run automated tests. Security Sensitive code also has unit tests marked as Security Sensitive and run after each commit regardless of whether the commit is to the main branch or to a feature (pull request) branch.
Azure
DAKS uses Microsoft Azure for the operating environment. There are two primary models for using Azure – 1) Infrastructure as a Service (IaaS) utilizing virtual machines that one can login to, or 2) Platform as a Service (PaaS) where developers do not login to the underlying machines. DAKS uses PaaS using various resources such as App Services, Function Apps, Azure SQL, Azure Storage, AppInsights (for error tracking), a Key Vault, and Traffic Managers.
As a result, the underlying machines are never “on the same network” with developer machines. This reduces the likelihood that viruses or malware are transmitted to the Azure environment. The underlying virtual machines are also kept up to date by Microsoft. Additionally, the Azure Portal uses Entra ID. Only 4 people have access to this environment and 100% use two-factor authentication for logging into the Azure Portal.
Deployment to Production
Azure DevOps is integrated with Azure for security and deployments take place directly from Azure DevOps to Azure services. The deployment pipelines (Releases) are setup to update the databases and then deploy code to servers located around the globe. These processes have access to the Azure Key Vault (to which only 2 developers have access).
Database and Storage Infrastructure Security
The storage accounts all use private access and require a key to gain access. The databases all use encryption at rest and transport (including backups), firewall rules, and each company has a dedicated database with its own unique password.
DAKS Security
DAKS uses Microsoft Identity for user registration and sign in. Both Entra ID and Username/Password models are supported. No passwords are ever stored in a database for either model. And of course, SSL or HTTPS is used for all pages in DAKS. The company a user belongs to is part of their authentication token, so company access is protected at the Identity level and not passed in as a parameter.
Summary
This post discusses key security practices. The full security involves many monitoring services and practices that are too numerous to mention in a blog post. The DAKS team has always put security first.
Leave a Reply