Re: Blackboard and security

["Jones, Mark B" <Mark.B.Jones () UTH TMC EDU>]

We chose “abandon it”.  We are moving from Blackboard to Canvas.

 

From: The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Eric 
Lukens
Sent: Wednesday, October 28, 2015 11:52 AM
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: Re: [SECURITY] Blackboard and security

 

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 <mailto: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 <tel:%28231%29-591-5613> 

VelPavlov () ferris edu <mailto: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 <mailto: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-7434
http://www.uni.edu/elukens/ 
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.uni.edu_elukens_&d=BQMFaQ&c=6vgNTiRn9_pqCD9hKx9JgXN1VapJQ8JVoF8oWH1AgfQ&r=jgMu8DNgV_dycz0rYwkNbEQq36F0BI5_Zpblz7C5LhM&m=jT3bh2XB086f39y_UpxuixEpGjrrXN_uq1HJEdK9KdU&s=dNoKG3TEDd1KHBXNGx2Qak6kBs8ZoDjaW_EVcUad0xs&e=>
 
"Security is a process, not a product."  Bruce Schneier

Attachment: smime.p7s
Description: