You're Doing it Wrong Part 8: Cybersecurity, Data Privacy and Regulatory Compliance.

Yes, you need security and data privacy, but you're going about it completely wrong.

Introduction

We are taking a step back from healthcare and health insurance to bring you a new series: You’re Doing it Wrong.  In this 15-part series we will discuss all the things that business people, et al. do that are counterproductive, risky and raise the cost of their own products and services and consequently the cost to you, dear reader, the consumer.  This eighth installment is an indictment of the entire cybersecurity industry: You can’t tack on security after the fact; it has to be built in.

We are taking a break from healthcare because there is no new real news.  The AI hype is just getting worse and will never pan out; the EMR vendors haven't realized that you can't document encounters with text or language; insurance companies rip off everyone, so we are stepping back and looking at the bigger picture.  If you need your weekly dose of healthcare, read our article Language Can’t Be Used To Document Patient Care.

The Situation

Software is complicated.  In an enterprise application there are dozens of moving parts that all have to be hand coded, and no you can’t do that with AI.  All of these hand coded parts then have to be fitted together, accepting the same parameters in number, datatype and protocol, they all have to be written so that they are fault tolerant, logged and secure.  There isn’t a generic language, most applications have a half dozen different languages and even types of languages to make them work.  Most focus on procedural language, one line at a time and decisions structures and loops, but the more important, set-based, languages are largely glossed over, or worse, left to a machine to write.

Security can’t be tacked on after everything else has been done.  Security has to be Role- and Group-based, not ad hoc.  Security can’t be applied to dozens or hundreds of little point solutions downloaded or purchased by a business.  Businesses also can’t put blanket security solutions over their “enterprise” applications like ServiceNow, Salesforce, Human Resources Information Systems (HRIS) or Enterprise Resource Planning (ERP).  These all have their own, disparate security models and they don’t play well together, even if token-based auth is implemented, allowing a security context, but not able to lift and shift users from one app to the other automatically, seamlessly or easily.

Building for regulatory compliance is also a fool’s errand.  If the politicians who made these laws had the first clue what they were doing, they wouldn't be wasting their time in government, they would be out actually solving problems.  For example, encryption at rest is a regulatory hurdle.  It requires a certificate to be installed on the database server to encrypt the data as it sits on disk.  

Great idea, what could go wrong?

If a bad actor is on your server, they just have to peruse the file structure, find your certificate and unencrypt your data.  

Encryption at rest is useless.  

This is why we have the largest and most successful companies in the world with huge data breaches and losing their clients’ data to hackers.

The Logical Conclusion

“Business as usual” thinking will conclude in business-as-usual results.  We will continue to have data breaches, identity theft, fraudulent transactions, spam emails and scams and all the other things we are now used to, until the system becomes unusable.  We will stand in a queue at our favorite retailer messaging or calling with our bank saying “yes, it is me and I’m trying to make a purchase” until we all just go back to cash.  Cash is not a viable alternative in 2026.  Cash introduces layers of manual intervention that cause losses, and soak up time and simply gum up the system.  

You will get mugged because you are carrying enough cash to pay for your groceries.

The Short Answer

Build or buy one system that runs your business with one security model.  None of the systems that a business uses is complicated by itself, and the money spent on the aforementioned dozens or hundreds of point solutions would easily pay for developers.  In the case of Salesforce, ServiceNow, SAP and most other “enterprise” systems, developers are required to finish the product so it works for your business in any case, so you already have the infrastructure and personnel necessary to build the one system you need.

The Slightly Longer Answer

Building software is not for the faint of heart, we demonstrated with all the “enterprise” systems basically being badly built and impossible to integrate and secure, and with the big consulting firms having given up on building software and going back to selling you a letter saying to install the “enterprise” applications that the copied and pasted your logo on to.

Here is the way we solve that problem at Sentia.

One Solution to Rule Them All

We build the one solution we discussed above with enterprise data in a single database repository.  This is called the Master Data Management (MDM) approach.  Also, all security, both authentication and authorization, for the enterprise is kept in another database repository, the Single Sign On (SSO). All the applications are linked together with generic APIs that are generated by a tool I wrote.

This is going to get a little technical, but these are things you need to know and understand that the big “enterprise” software vendors can’t and won’t tell you.  They can’t because they don't do it.  

Master Data Management

The MDM is where we keep all the things we will need across all applications, like people, businesses, addresses, phone numbers, emails and the like.

Single Sign On

The SSO is where we relate lists of users with lists of groups giving each user the authorizations granted to that group.   You can assign individual rights to individual users as necessary, but group-based authorization is best.

Security and Multitenancy

With each login the user is granted a Globally Unique Identifier (GUID) that is called a SessionGUID.  The identifier identifies the user and his or her session.  It is unique in the universe and can’t be guessed.  This GUID is kept in the User table in each separate application in the suite, and is adequate to filter out the things that user can and can’t see.  Multitenancy is the technique of keeping everyone in the same database to reduce cost and improve reliability and performance and this GUID is the way we do that.  

This is new in the world and we call it Relational Multitenancy, since we don’t have to have an identifier in each table for the company or entity, we can relate back to the user table.  This also puts the security at the database level.  That means that I can give the bad guys the login and password for the database and they still can’t get anything.  They have to supply a valid SessionGUID to get any data at all.  

The Generic Application Programming Interface (API)

The API is nothing more than a transport layer between the database and either the User Interface (UI) or another coordination layer we will talk about next.  This is all generated, as stated earlier, so that every one of them looks exactly the same, making troubleshooting routine and relatively easy.

Backend For Frontend (BFF)

The BFF layer is a coordination layer between the MDM, SSO, the individual application we are working in, and a layer to combine any external data we will need, either from another of our generic APIs or from an external source like a geography service that validates addresses before they are saved in the system.  The BFF is also used to tailor the data returned for the screen it is intended for, so you will probably have a BFF for each different type of screen, relative to its size.

User Interface (UI)

The UI is everything the user sees when they log in to do their work.  Ours is different in that we DO NOT use any open source (insecure) frameworks like JavaScript, Angular, React, Vue, or Node.  In 2015 several of the big players like Google,  Microsoft, Mozilla and Apple got together to eliminate the resource intensive, JavaScript and its performance limitations for compute-intensive tasks like games, simulations, and data processing.  This allows us to run native, compiled C#, our procedural programming language of choice, directly in the browser.  

This has never caught on, unfortunately, but it is the standard and it is better than the JavaScript it replaces.  The fact is that most developers are so inured to JavaScript that they can’t even imagine the effort to switch to a real, viable  programming language.

And that is it.  That is how you make one application to rule them all and eliminate the need for security workarounds, integration and finishing other people’s products when they aren’t smart enough to do it themselves.  

Conclusions

We have shown a way to make an end run around the mess of a security model foisted on you by big, “enterprise” software vendors.

We have shown a way to keep your data private, regardless of a breach in your network firewall or security.

We have shown why regulation and compliance is just not good enough and what is better.

We have shown a way to get off the subscription treadmill of purchased software.  

We have shown a way to do what your business needs to have done, not what some MBA somewhere thinks your business needs to be doing.

We have shown a way to differentiate your business from everyone else by doing things differently and better, faster and cheaper.

Remember, this is part eight of a fifteen-part series about how businesses are being run incorrectly by business people who probably haven’t been trained in the intricacies of writing and deploying software.  We are demonstrating not only the problems of modern business, but real, viable solutions.

I will be putting out one or maybe two articles per week.  If you liked what you read or want to relate your personal experiences, contact us here, on our site, SentiaHealth.com, our parent company SentiaSystems.com, or send us an email to info@sentiasystems.com or info@sentiahealth.com.  By here I mean comment and tell me that I am a cotton headed ninny muggins or whatever else you need to say.