Quite often, technical matters that are as clear as day to techie-professionals are somewhat tricky to explain to non-techie-folks. Still, I’m going to have a go at doing just that here today. Why? Because it’s a darn exciting and amazingly interesting world! And who knows – maybe this read could inspire you to become a cybersecurity professional?!…
Let’s say you need to build a house. And not just a standard-format house, but something unique – custom-built to satisfy all your whims and wishes. First you need an architect who’ll draw up the design based on what you tell them; the design is eventually decided upon and agreed; project documentation appears, as does the contractor who’ll be carrying out the construction work; building inspectors keep an eye on quality; while at the same time interior designers draw up how things will look inside, again as per your say-so; in short – all the processes you generally need when constructing a built-to-order home. Many of the works are unique, as per your specific instructions, but practically everything uses standard materials and items: bricks, mortar, concrete, fixtures and fittings, and so on.
Well the same goes for the development of software.
Many of the works involved in development are also unique, requiring architects, designers, technical documentation, engineer-programmers… and often specific knowledge and skills. But in the process of development of any software a great many standard building bricks libraries are used, which carry out all sorts of ‘everyday’ functions. Like when you build a house – you build the walls with standard bricks; the same goes for software products: modules with all sorts of different functionalities use a great many standardized libraries, [~= bricks].
Ok, that should now be clear to everyone. But where does cybersecurity come into all of this?
Well, digital maliciousness… it’s kinda the same as house-building construction defects – which may be either trivial or critical.
Let’s say there’s some minor damage done to a completed house that’s ready to move into, which isn’t all that bad. You just remedy the issue: plaster over, re-paint, re-tile. But what if the issue is deep within the construction elements? Like toxic materials that were used in construction in the past? Yes, it can become expensive painful.
Well the same goes for software. If a contagion attaches itself to the outside, it’s possible to get rid of it: lance it off, clean up the wound, get the software back on its feet. But if the digital contamination gets deep inside – into the libraries and modules [= bricks] out of which the final product [house] is built… then you’ve got some serious trouble on your hands. And it just so happens that finding such deep digital pestilence can be reeeaaally tricky; actually extracting the poison out of the working business process – more so.
That’s all a bit abstract; so how about some examples? Actually, there are plenty of those. Here are a few…
Even in the long-distant past, during the Windows 98 era, there was one such incident when the Chernobyl virus (also called CIH, or Spacefiller) found its way into the distributions of computer games of various developers – and from there it spread right round the world. A similar thing happened years later in the 2000s: a cyber-infection called Induc penetrated Delphi libraries.
Thus, what we have are cyberthreats attacking businesses from outside, but also the more serious threats from a different type of cyber-disease that manages to get inside the internal infrastructure of a software company and poison a product under development.
Let’s use another figurative example to explain all this – a trip to your local supermarket to get the week’s groceries in… during mask-and-glove-wearing, antiseptic-drenching lockdown!… Yes, I’m using this timely example as I’m sure you’ll all know it rather well (unless you’re the Queen or some other VIP, perhaps live off the land and don’t use supermarkets… but I digress).
So yes: you’ve grabbed the reusable shopping bags, washed your hands for 20 seconds with soap, donned the faced mask, put the gloves on, and off you go. And that’s about it for your corona-protective measures. But once you’re at the supermarket you’re at the mercy of the good sense and social responsibility and sanitary measures of the supermarket itself plus every single producer of all the stuff that you can buy in it. Then there are all the delivery workers, packing workers, warehouse workers, drivers. And at any link in this long chain, someone could accidentally (or on purpose) sneeze right onto your potatoes!
Well it’s the same in the digital world – only magnified.
For the supply chain of modern-day ‘hybrid’ ecosystems of IT development is much, much longer, while at the same time we catch more than 300,000 brand new cyber-maliciousnesses EVERY DAY! What’s more, the complexity of all that brand new maliciousness itself is rising constantly. To try and control how much hand-washing and mask-and-glove wearing is going on at every developer of every separate software component, plus how effective cyber-protection systems of the numerous suppliers of cloud services are… – it’s all an incredibly difficult task. Even more difficult if a used product is open-source, and its assembly is fashionably automated and works with default trust settings and on-the-fly.
All rather worrying. But when you also learn that, of late, attacks on supply chains happen to be among most advanced cyber-evil around – it gets all rather yikes. Example: the ShadowPad group attacked financial organizations via a particular brand of server-infrastructure management software. Other sophisticated cybercriminals attack open source libraries, while our industry colleagues have reminded us that developers are mostly unable to sufficiently verify that components they install that use various libraries don’t contain malicious code.
Here’s another example: attacks on libraries of containers, like those of Docker Hub. On the one hand, using containers makes the development of apps and services more convenient, more agile. On the other, more often than not developers don’t build their own containers and instead download ready-made ones – and inside… – much like a magician’s hat – there could be anything lurking. Like a dove, or your car keys that were in your pocket. Or a rabbit. Or Alien! :) ->
So what we get are different camps seeking different things: the developers want their software product out the door asap; the devops (development operations, including automation) guys champion the use of accessible components from cloud platforms at all stages; the company cybersecurity chaps look on in horror and self-medicate; while the user – poor thing – risks infection with not just one Trojan, but a whole herd of them!
But, hey – that’s what we’re here for! Whenever there are complex problems need sorting – we sort them!
And for this very serious problem [drum roll, trumpets, applause], we’ve gone and turbo-charged our Kaspersky Hybrid Cloud Security.
Now, the sensible developer – much like the sensible customer who’s commissioned a house to be built – wants to be sure that the containers he/she uses for building a development environment, the assembly of the toolchain, and also all the existing binary program modules [bricks] are without defects. To do so, at different stages of the application’s development, he/she needs to carefully check all the components and also create a safe environment for testing everything in. And that’s just what our Hybrid Cloud Security does.
If a container is used, our solution takes it apart – separates it up into different layers. It then shows on which layer a threat is found, and may even suggest the optimal course of action. And given binary software components, we put the collected files through our various threat-detection technologies – Kaspersky Security Network, heuristic models, signatures, and assorted HuMachine Intelligence – so as to be able to give an indication as to whether lurking inside a ready-made module there’s malicious functionality and, if so – where exactly it is.
The whole collection of services is accessible via a single console with a set of interfaces for full automation possibilities. Thus, using our solution means development tempo isn’t lowered, while the level of protection of infrastructure – including distributed infrastructure – is increased! As a result everyone’s happy: the developers, the devops, and the cybersecurity guys and girls – including the CISO. Moreover, our Hybrid Cloud Security supports the largest cloud platforms – Google Cloud, AWS and Microsoft Azure; the most popular virtualization platforms – like Hyper-V, Citrix, VMware, and others; and of course – Linux and Windows servers that work on these platforms.
So there you have it folks: for all those toilers involved in the processes of development of software – our Hybrid Cloud Security really is a useful ‘pill’ that will help out in their work – and keep things safe. And that goes for both the developer and the consumer of their applications ).
PS: More observant readers may have noticed that our product and tech announcements have become more frequent. And indeed they have. Our plans for new products and services are as ambitious as ever, and nothing is being postponed or cancelled – even during lockdown. All our plans that have been announced are going ahead – no changes. For us, biological viruses are no hindrance! Just like computer viruses, then :).