Re: Blackboard and security

[Eric Lukens <eric.lukens () UNI EDU>]

Blackboard certainly isn't the only company to request/require poor
security practices. I just got a request from a vendor of one of our
applications that accepts credit cards to install Java, lower the Java
security permissions, and give the users admin rights so that a new VPN
application could easily install. The software VPN application was required
by the vendor's auditors to meet PCI DSS. However, clearly they don't care
about our compliance.

With Blackboard, we run into some other interesting problems. Most
environments are probably not running the same code. They've decided to
patch at different times, decided to apply different patches, Blackboard
has provided patches for specific problems to specific customers via
support only, and different organizations may have purchased different
components. So what works for one place might not for another.

So broadly with all these vendors that require poor security practices,
what do you do in situations like this? Overall, you end up implementing as
much as you can, then accepting the risk created by those vulnerabilities
that cannot be eliminated.

The things in this list are not mutually exclusive, and generally are all
part of a good security structure.

Defy it. Generally, we defy their poor requirements in applications and do
our own testing. Many times we find that requests to disable firewalls and
so forth are there just so the vendor doesn't have to document those
settings themselves. Use detailed audit logging on the system to figure out
where the hardening needs to be "softened" a little for the
application--document those softenings well and justify them. Get the
application working fine with as much of the hardening intact. But, when
things go wrong, you generally have to either replicate the issue on a test
system that is not hardened, or temporarily remove the hardening from the
production machine. Either way, you're going to need to have the
infrastructure in place to rapidly add and remove the hardening and have
ample licenses and servers/VMs to maintain multiple test systems. Last I
knew, we had four non-production Blackboard clusters used for various
purposes. Here, information sharing between Universities can be useful to
know which CIS or other hardening settings cause problems and which do not.

Isolate it. This is really most vendors point you towards--they see that it
is your job to provide an environment where their junk application can run
securely. There generally are various database firewalls, reverse proxies,
layer 7 firewalls that could be configured strictly to create a barrier
around the servers. Put the servers in their own subnet/vlan and use the
various db firewalls, reverse proxies and layer 7 firewalls to only allow
the exact traffic that is supposed to flow and nothing more. URLs and
content submitted should be filtered by the security appliances before they
can reach the server. Inspecting the content of the HTTPS traffic is
required. Blackboard's nature makes this difficult, as you likely can't
require your users to VPN to use it when off-campus--they want it
publicly-facing, so this solution isn't as drastic and successful as it can
be for other applications.

Monitor it. Regardless of if the application is still configured as
instructed by the vendor or hardened by your team, put many monitoring
solutions in place. Watch the logs, the network traffic, the changes to the
file system. Here, we aren't preventing any attacks, we're just trying to
be aware of them as fast as possible to limit the damage. This is
important, as we should assume the Blackboard code that we have no control
over can be compromised on its own, regardless of how secure we make
everything else.

Accept it. The vendor requires this poor configuration, you could configure
the application according to their specifications. Nothing can absolve you
of all risk, but really the "failure" could be defined as the decision to
purchase a product requiring poor security, rather than IT's configuration
of the server itself. Get administration to accept the risk. If you put in
place the monitoring solutions and isolation, you can fairly well argue
that your environment is configured according to the application vendor's
specifications and placed in an environment that follows industry best
practices.

More drastically...

Outsource it. Some of these companies making junk apps that we're required
to use, including Blackboard, offer hosting or other options where more of
the work is done by them. A solid contract is then necessary to protect the
University, but transferring risk is sometimes a good solution.

Abandon it. Push that a proper solution needs to be found. With something
like Blackboard, you might not be able to find another solution that meets
the educational requirements, but for other software, there often is a
vendor who provides better security, or is willing to work with you on
security. The IT and security aspects of an application need to be an
important part of the procurement process, not just what the end-users
want--but don't become too inflexible, or they'll just find ways to work
around IT.



On Wed, Oct 28, 2015 at 10:36 AM, Velislav K Pavlov <
VelislavPavlov () ferris edu> wrote:

> For those of you using Blackboard Learn, can you please share your
> experience with hardening the server OS, apps, and databases for Blackboard
> related services? The vendor recommends to disable all endpoint protection
> including host based firewall and antimalware. Do you have a hardening
> guide for servers running Blackboard services that you can share? I am also
> interested in collaboration with anyone who faces similar predicaments with
> Blackboard and security. Thank you for the thought and consideration.
>
>
>
> *Vel Pavlov | Sr. IT Security Analyst*
> M.Sc., CISSP, C|EH, C)PTE, Security+,
>
> CNA, MPCS, ITIL, A+
>
> Big Rapids, MI 49307
> Phone (231)-591-5613
>
> VelPavlov () ferris edu
>
>
>
> Notice:This email message and any attachments are for the confidential use
> of the intended recipient. If that isn’t you, please do not read the
> message or attachments, or distribute or act in reliance on them. If you
> have received this message by mistake, please immediately notify
> VelPavlov () ferris edu and delete this message and any attachments. Thank
> you.



-- 

Eric C. Lukens
IT Security Policy and Risk Assessment Analyst
ITS-Network Services
Curris Business Building 15
University of Northern Iowa
Cedar Falls, IA 50614-0121
319-273-7434http://www.uni.edu/elukens/

"Security is a process, not a product."  Bruce Schneier