A lot of our focus is helping the developers and, of course, various other
project team members to be able to build secure systems.
We know that that requires the effort of everyone involved because
providing satisfactory security controls in a computer system is in
itself a system design problem, not just an application problem. But
it's a combination of hardware, software,
communications,
physical, personnel, and administrative procedural safeguards that
are required for comprehensive security. In particular, software
safeguards alone are not sufficient.
That's why it's important we deploy secure applications in a secure environment.
There are many different options that organizations will look
at when it comes to developing applications.
Should they buy an application that's already out there?
There are many advantages to that as speed, but of course, then
you're stuck with whatever somebody else built.
How much can you customize it?
What's it going to cost to maintain it?
Who's going to have possession of the source code?
And of course, the other is to build it ourselves,
which requires us to have the expertise and time to be able to do that, but
then we get something that was built specifically for our needs. When it
comes to application development, the traditional model of application
development was to build an application,
a self‑contained unit that did everything. But a lot of what we do today
is to break things into manageable, we could call, bite‑sized pieces in
what we call microservices. For example,
the old type of monolithic architecture meant that we would write an application
that would run on some type of a hardware, and that application did everything
from taking input to processing to generating reports to storing the data all in
one big, should we say here, combined process. To make any change meant taking
this very large structure,
making the changes where it was required, and then
retesting the whole thing as well.
But we saw the development of things like object‑oriented
programming moving towards agile and extreme programming and
a lot of our DevOps world today,
which is trying to break things into smaller pieces, and we could call
this even a microservices architecture. We write an application as a
whole series of individual microservices,
each one that does its own task and just does that. But in order
to provide the end result the business needs,
we have to combine many of those microservices together, and
those microservices can actually run in different places and
on different platforms as well.
So, this enables us to be much more flexible to make changes and to use
services that were actually developed somewhere else as well.
Now the foundation of microservices is that each one of these is
independent. It does its job, and it doesn't require anybody else
in order to do its job properly.
We say,
therefore, it's loosely coupled. We can join it to other
microservices easily, but then we can break that and join it
to something else just as well.
The problem, of course, is that if something is tightly coupled,
there is a dependency. If I change one part of this couple,
then I'm probably going to affect the other.
So, we remove part of the risk of dependencies by going to
loosely coupled, but then we need something to be highly
cohesive as well that it does what it does on its own without
needing those other dependencies.
We use very fast, lightweight communications protocols,
so we're not dealing with something that's going to add a
huge administrative burden when we're going to try to
communicate from one element to another.
We want to have granular access controls, but those have
to be built within the microservices.
We can't just build an access control for the application because
the application could be made up of many different services, and,
of course, each of those services could change as various business
requirements change as well.
So we should build a recognition of the need for access control within those
microservices. We say that that is then very granular as well.
The idea of APIs is to allow applications to talk to each other,
application program interfaces. These act as an interface between system
elements and allow us to aggregate data or services for many different
microservices into one combined service.
But the problem with APIs is there's a lot of them out there that are insecure.
We have to carefully test any API we're going to use to make
sure it's not leaking data to an observer.