Prototyping Malicious IP Protection on the Cloud in Two Days with CAIOS
This article highlights the rapid development of a software component to enhance cloud security using the latest ‘Infrastructure from Code’ approach.
In our last article, “Improve Cloud Software Development 10x by Embracing ‘CAIOS’,” we explained how the Cloud AI Operating System compiles standard programming code, in a language like Python, into an executable with a cloud-deployed specification stack — with 10x the speed of standard DevOps. CAIOS accomplishes this through a built-in Cloud Compiler that interprets the code and auto-generates the necessary resource declarations and usage policies on-the-fly. What used to take a solution architect or developer days to create now can be accomplished in a single sitting because they are able to focus on the business logic, not cloud deployment details.
While this productivity increase has major implications for major cloud software projects, it also means that simpler software components, including micro-services, can be deployed in the cloud in a single sitting.
Here, we check in with Etzik Bega, VP of Product Management for BST LABS and the CAIOS team, about how one user created a cloud software component to monitor known Malicious IP Addresses and automatically block them from connecting to a cloud account. The most noteworthy aspect of this project is the speed and incremental approach achieved in the concept-to-development/test/deployment lifecycle.
Etzik, how did the need for a Malicious IP Address Blocker come about?
An organization using CAIOS wanted to strengthen their cloud account security, by referencing various data sources that list known and suspected malicious IP addresses that have attacked cloud accounts. They realized this was a great app to build with CAIOS because it is a real-world IT operations need, would be quick to develop, uses already-available data sources, and mainly needs easy deployment to the Cloud.
What did it involve?
We first identified the useful resources the user organization has access to, namely: internal spreadsheets and known, open source intelligence (OSINT) databases of malicious IPs with a published schema; and their AWS Virtual Private Cloud logs (VPC Flows). The logic is as follows:
- Capture the malicious IP lists’ locations and schemas for the spreadsheets and open source intelligence DBs, and merge the lists.
- Access real-time network access data from several log files, selecting the attributes needed, including Source and Target IP address.
- Match the malicious IP list against the access request log as well as the cloud/network account’s blocked IP address list.
- Note any situation where an IP address requesting access is on a malicious IP list, but not on the account’s blocked IP address list, and then add the noted IP Addresses to the blocked list.
- Provide a special notification should there have been a situation where a malicious IP attempted to connect at a point in time where the address was not already on the blocked list.
Was this project completed all at once?
The client developed the application iteratively. In the first iteration, the list of newly uncovered malicious IPs was sent to DevSecOps by email for action. Then they added scheduled checks, then automated the updates to the blocking lists. There are plans to make the list of OSINT sources and cloud accounts dynamically managed, instead of hard-coded.
Why did CAIOS make this easy?
To begin with, CAIOS compiles code in a common language like Python to a complete cloud configuration specification, involving hundreds of lines of resource setup, with just a single run command. This makes nearly effortless serverless cloud computing a reality.
In addition, you switch easily from local unit testing to local integrated testing, then to remote/cloud testing with a single run parameter. You actually want to keep a good deal of testing on your local workstation, as it’s faster and less costly. Spending 80% of development and testing in the local environment is a common ratio. Again, the development framework adjusts to the test mode automatically. That’s what makes it simple to expand your functionality iteratively with CAIOS.
By the way, CAIOS also handles library management in the cloud. In this case, the customer used the “gspread” library for Google Sheets access and Pandas for data analysis in Python. We’ve already configured access to the latest library versions, customised for cloud use, within CAIOS. You simply have to install the functions needed. If you had to import all the libraries needed yourself and get them working in the cloud, it could take hours.
Finally, since the solution source code is stored in the cloud as well, collaborative development or simply getting a fresh pair of eyes on the solution is easier than with siloed workstations and distribution version control activities.
How extensive was the programming?
The whole application took less than 150 lines of Python code. Much of that was on basic functions including extracting and joining the data sources and generating the emailed report.
Remember that CAIOS takes care of building the serverless cloud configuration script, which takes up a thousand or more lines itself, but the developer never has to be concerned about that.
How long did it take to code and to deploy?
The client built the prototype — that is, the data access and list screening through email alert notifications — in under a day. A good deal of that time is not coding per se, but rather getting a feel for the data source contents, and thinking through where they’d want to eventually take the application — good practices for any solution architect.
Because deployment in the serverless cloud happens is instantly handled by CAIOS, there isn’t any extra time involved in technically deploying the code after testing it. This points to another benefit of CAIOS — allowing a solution architect to focus his or her attention on the domain requirements (in this case, cloud application security / hacking threats, and available data) and delegate concerns about porting to the cloud to CAIOS.
To go from working prototype to in-production application probably took two weeks duration, but possibly one person-day of that was taken up by finishing touches on the code like adding authentication and scheduling. You still need to get organisational buy-in with stakeholders, agree on responsibilities and access roles, etc., which takes most of the time between prototyping and production
Can you achieve the same results with other common tools?
While the application logic is straightforward, it’s not really easy to deploy it to the Cloud with other tools that come immediately to mind. Jupyter NoteBook isn’t great for this — too heavy and not oriented to building a final solution. Cloud9 is OK, but lacks a cloud-oriented REPL (read-eval-print-loop). In general, a lot of data access tools for the cloud are intended for deep, data scientist exploration. CAIOS tends to focus more on the needs of a Solution Architect, who wants to deploy an application efficiently.
What are your key takeaways from this customer project?
This is a very typical scenario of how the CAIOS team and our clients are working. We use sprints to prioritize, schedule and deliver functionality. Even within a sprint, we often develop iteratively, through a sequence of small steps, each one bringing some value to the table. The fact that it was DevOps, in this case, is insignificant. CAIOS is being used in a similar fashion to build an HR app right now. …That’s for another post.
Visit caios.io for more information and free access to CAIOS.
