In this 5 part series, we will summarize topics covered at a recent Tap into Security event. The first installment details a presentation made by consultant Abbey Vangeloff illustrating a laboratory assessment program implemented for a US based client.
Yahara Software was selected to lead a program to improve the informatics for a national organization that works with public health labs. They needed to pair informatics with analytics and the pubic labs tend to lag behind in this type of analysis. They wanted to gather a baseline for what was the capability This information would then be collected at the national level to report to the public as well as used to design and implement process improvements at a local level. They wanted to collect information on 21 different areas, which is fair amount of specific data, but allow the local labs to report only the data they wanted to be made public. Because of this, we needed to make sure that the system we built for them would only show information to them that was their data set and make them comfortable that they were only releasing data at the national level that they wanted shared.
Diagram of Laboratory Assessment Data Flows
The crux of this project was to address the security needs not just from a technical standpoint, but also from a user perspective We tend to think of security from a software perspective, avoiding attacks, but there is a large human component as well. It’s important to design software such that your users are comfortable with how it is set up, and it is supported by the operational policies. Most times people want to follow best practices but they might not know how to do it.
In this case, we had a large multi-tenant system, so we had to accommodate that complexity while still creating a system that was easy to maintain and one that users would want to interact with. There’s always a dichotomy between having data in one place where you can wrap it all in the same security but someone could access all of it with one security breach and having your data segregated so that it isn’t as easy to access, but is harder to maintain. In this system, we went with a single database but used claims space authentication and clearly defined user roles to create separation. So, it was one database but users could only get to the data they were allowed to.
This type of configuration was especially important in this particular case because we had two different levels of admins, a local and a national. In most cases, you’d assume that the national admins would have more access, but in this case we wanted the local admins to be able to restrict what data flowed up to the national level as well as manage their own systems separately, without the need to call on the national admins for everything. As an example, think of users at the local level. The national level lab doesn’t want to be the one setting up each user role and password. This would be impossible to maintain and you’d lose track of all the users. So we set up a local admin level at the local labs that had access to everything at their local level: they set up users, they could set up lab demographics, they could create their own assessments, and they could determine what information trickled up to the national level. This granularity helped the local admins feel safe about who had access to their data, and what data was being shared.
In addition to user roles, we thought about how the design of the software and the user experience will enhance security. If users don’t know what each button does, they can’t be secure. Part of what we did was install checks and balances, so each role could submit data to the next level but not all the way up to the national level. In addition, we created a system to educate the end users and the lab users of the software as to how each process went and what each action did. We worked with both the national and local level to dig in and create each roles with appropriate security. Then we created videos and a glossary so that if users had a question they could access the information they need when they needed it so that people know what each action does. After all, it was their job to answer the questions and our job to keep them secure. One of the best way to do this it to make sure they are comfortable with the workflows they are asked to use.
TAKE HOME POINTS:
• A key in designing a system with complex security needs is to strike the optimal balance between operational cost of support, user convenience and architectural robustness
• Architecture based upon our technical framework which has key security functions built-in including the ability to support multi-tenant systems while providing multiple local roles for user access control.
• For security to be effective it must be operationally consistent with the existing user expectations and integrate with the workflow as seamlessly as possible.