“BatCave” indicates the CMS’s progress towards moving to the cloud

Much like the iconic Batman superhero, the healthcare and medical services centers’ technological environment has two identities.

From the outside, many would think that a CMS has an old, boring deficit stuck in yesteryear with mainframes and COBOL.

But find the secret key in the bust to unlock the door behind the bookcase, go down the shaft and you’ll spot the BatCave.

This is a metaphor for the progress of CMS over the past decade, but also…

Read more

Much like the iconic Batman superhero, the healthcare and medical services centers’ technological environment has two identities.

From the outside, many would think that a CMS has an old, boring deficit stuck in yesteryear with mainframes and COBOL.

But find the secret key in the bust to unlock the door behind the bookcase, go down the shaft and you’ll spot the BatCave.

This is a metaphor for CMS’s progress over the past decade, but it’s also literal in the sense that the agency has developed a new IT modernization initiative called Bat Cave.

Robert Wood is the Chief Information Security Officer at CMS.

“The official government acronym is Continuous Authorization and Verification Engine, and what it really stands for is a software factory or container-based platform to streamline software development efforts, ATO setup efforts, ongoing maintenance, and uptime that goes into building a system,” said Robert Wood, CMS’ chief information security officer. , in an interview with the Federal News Network: “It’s a DevSecOps platform and software factory where I almost see it as one of a kind in some ways. It’s a combination of the accumulation of technologies, processes, and culture that goes into building software, getting out quickly, and aligning with principles of continuous deployment. “

Wood’s team is leading the BatCave effort because to build software faster, the security stack has to reduce friction, ensure stability and resilience, and most of all, make as much of the security process as automated and continuous as possible.

While some may view CMS as being stuck in the past with mainframes and COBOL, the agency over the past few years has been going strong. Transfer systems and data to the cloud.

CMS Chief Information Officer Rajeev Uppal said on a recent AFCEA Health IT Day that the agency has already moved more than 90 systems to the cloud out of 200.

“There are some things that are going to take longer to go to the cloud. For example, we have claims processing. It’s a 40-year-old system running on the mainframe. We’re taking pieces and moving them to the cloud. That’s going to take some time and we have to be careful how we do these things. “Ultimately, I think almost everything will be in the cloud. CMS has the potential to have the largest cloud footprint in the civilian sector. We’re on our way.”

Borrowed from other Air Force

Bat Kaf is not necessarily a new concept. CMS worked closely and modeled it on A.Air Force One platform Exertion.

CMS developers are not required to use BatCave, so Wood knows she has to provide value and incentives to attract users.

“We are collaborating and having discussions with the Air Force because they’ve also done so in a very federal environment, which is similar to how we have to operate in CMS. Everyone has their own money and they do their own thing.” Service is not accredited by mandate, but by choice. We have to have the right incentive levers and value proposition in place for someone to choose to consume a centralized service. So there are a lot of lessons to be learned from the Navy’s efforts in the Air Force’s efforts.”

To attract these users, Wood said one of the big lessons he learned from the Air Force is to focus on community and user needs.

“I think it’s really easy to fall into the trap of building what you think your community needs, rather than actually listening to them or letting the data move where you want it to go. In our case, we did a lot of user research, a lot of user validation, and a lot of data research.” Around what our systems look like, the ATO process and things like that, we had these efforts leading up to BatCave that really informed how we’re going to build and what we’re going to build.” “We’ve been researching human-centered design all along, and we think about it in terms of flywheel, value-driven. Doing something like this requires that level of user engagement and community involvement.”

Inheritance security control

Wood said CMS took the DevSecOps platform from awarding contracts to production in less than a year and currently has six teams using it. He said several other mission areas across the CMS are evaluating how the tools can be used in the future.

“It’s not going to be a good fit for everyone. We realize that. But those who are running containerized workloads, who are trying to move faster with software, who are running things in the cloud, who are running web services, APIs, it’s likely that Very appropriate,” he said. “They may benefit from not having to worry about ATO expenses anymore. They may benefit from being able to change and deploy their software very quickly without having to go through the costly and time-consuming security impact analysis process every time they make a new release or want to introduce a new feature.” All of this contributes to faster task release and a quicker time to market.”

One of the biggest advantages of the BatCave platform, Wood said, is that developers inherit roughly 80% of the required security controls. This means that they only have to test the remaining 20%, which reduces the time from development to production.

We didn’t start out trying to get to 80%. We basically built what we felt was an ideal minimum viable product (MVP), and we went and started doing the hard work of mapping control of all the different things that go into it in this very modular way. We anticipate that because we’re able to add more and more things to the pipelines because that was just MVP,” he said. “The rest of the things like security monitoring activities and things like that are things that we can also start to systematically incorporate into the process. This includes things like collecting logs, aggregating them into our data lake, and producing a software bill of materials (SBOM). This all falls to the development teams, but we can put them on charge to be successful and internalize the artifacts in a way that we can constantly monitor them, so they get to the point where we’re just as comfortable as we feel comfortable putting them in a constant state of delegation.”

Leave a Comment