The EU’s fight against disinformation and online safety for its citizens just ramped up with a solid response in the form of the Digital Services Act. It seeks to address the exploitive risks our citizens are exposed to in an online setting, which includes the seemingly feral yet organized spread of disinformation. For the tech industry, this means some internal adjustments to its compliance team with a more substantial augmentation of its digital compliance program. The act opens in clause (1) with “Information society services and especially intermediary services have become an important part of the Union’s economy and the daily life of Union citizens”. All national laws around digital safety are complimentary to this EU-level act, which brings in new compliance structures along with clear and piercing enforcement powers.
We techies need to be responsive in the DevOps field around agile deployments given the need for speed in remediation actions. Non-compliant companies can be fined up to 6% (Article 52, section 3) of their annual worldwide turnover, which gives teeth to the EU’s new act and commercial priority to any remediation actions required. First and foremost, the changes required may not be only in the application layer where interactive algorithmic changes are executed, changes may be required at the infrastructure layer also. We engineers can be a sentimental lot that loves what we get working and thus can be slow to change. This is a mindset that can present security risks on an ongoing basis, which includes dogmatism around larger-scale changes such as architectural changes impacting our infrastructure.
Let's look at a use case that requires a well-prepared and skilled approach for an agile-based response. If you support an interactive (dynamic) website that hosts interactive digital products and has an architecture that has not been revised since 2014, how do you ensure your sensitive data content is not been compromised in its submission and storage? If this cannot be clearly answered, architectural solutions that temporarily house and analyse data payloads for sensitivity comes into scope. An example solution would be (on AWS) a well-architected framework having a gateway account for data processing at the boundary to the internet. This account would house S3 storage instances and AWS Macie managed service to do the sensitive PII data analysis before sending the processed payload internally to its final storage destination in another AWS (internal) account. Making this happen is where DevOps comes in.
Some things to think of when faced with the challenges presented in remediation requirements for compliance under the Digital Services Act.
- Segregate pipeline projects (or pipelines) in your tool of choice (e.g. Jenkins, Azure DevOps, AWS CodeStar) to ensure a bottom-up approach is enforced via segregation of concerns. Make sure your service connection tokens/service principals are identifiable for their unique purpose (e.g. deploy infrastructure, application, etc).
- Do your deployments as sequenced sub-steps in an overall agile project where you iterate your infrastructure changes first (e.g. new account from AWS organizations, then provision s3s, AWS Macie with compliance spec requirements, then repoint edge gateways). Then iterate with application level changes in line with requirements (e.g. algorithmic changes), etc.
- Ensure your pipelines conform to best practices with secure secrets management, and no exposed data in transfer (or at rest) when operating your CICD tools.
- Jenkins requires more configuration given its narrow modular design. Managed cloud CICD tools have an advantage with their cloud-native managed service relieving the engineer of a great deal of system administration when setting up their CICD projects. If you don’t know Jenkins intimately (and it's fun to learn by the way), then go with your cloud-native CICD tool of choice.
- Agile project management is best served in general terms by projects that are planned in an iterative approach prefaced with a ranking by critical path and risk. If you think there is a lack of guidance on priority and logical sequencing of steps in your project then speak up. Doing so before the project starts will do your company a huge favour in identifying missed risks. If nothing else, clarification received will leave you in a more informed position entering the project and working forward to a successful outcome.
There is no doubt that the CALMS DevOps model will become more and more important to all digital companies that rise to the challenges presented in this technological era. Companies who adopt it in their move to become closer to their online customer will see agile DevOps practices becoming the norm and not a project requirement in remediation. This paradigm shift may start with a pressured nudge from a regulator, but if responded to correctly can lead to a new era in your digital business's viability, competitiveness and vitality for the longer term. Stay tuned for more on DevOps in this blog along with articles on other areas of interest in the Writing and Cloud Infrastructure arenas. To not miss out on any updates on my availability, tips on related areas or anything of interest to all, sign up for one of my newsletters in the footer of any page on Maolte. I look forward to us becoming pen pals!
