Re: Security vs. Business Process. Does Business Process trump Security Process?

[Joe St Sauver <joe () OREGON UOREGON EDU>]

Randy mentioned:

#The recent thread on blocking email attachments reminds me of a
#discussion I had a couple of months ago on how IT sysadmins might be
#making our overall security posture worse by pursuing the wrong
#security strategy.

Very well said! I was also struck by some other bits you mentioned,
too, including...

#[...] it was user awareness not technical issues that caused most
#of the problems

Yep... and thus it can be tremendously helpful if you can build a
security-aware user population, and encourage a healthy degree of
skepticism (skeptical/cynical users don't tend to dutifully respond
in a sheep-like unthinking way with their passwords when a phisher
demands they supply them, for example).

#[...] In other words, I clamped down for efficiency's sake.

Local optimization. I would argue that many tactics which are locally
efficient for security organizations may be be globally inefficient
for the campus as a whole (which I think was the point you were making)

#When we analyze WHY [the user is bypassing a security restriction]
#we find it's because a security restriction prevents them
#from doing their job efficiently.

And that's one of the reasons why tight economic times really can challenge
some security practices. If there's slack in the system, a semi-sensical
"tax" on operations can be absorbed, but when times get tight and people
are doing their best to make do with too little in the way of staff and
other resources, that's when folks tend to "do what they have to do."

#We were told that the institution blocks video downloads.

Blocking spam or phishing or executable attachments or HTML formatted
email I get, but blocking video from a security point of view I don't
understand.

If the institution was doing that because they were bandwidth
constrained, I could understand that. But just to arbitrarily block
video for "security reasons" strikes me as a less than helpful
policy. Was there any explanation for why that policy was adopted?

#Basically, they downloaded the video (yes, it was legit) to their
#home computer and then used a VPN to transfer the file to the work
#computer. This bypassed the IPS on their campus. The
#dept produces videos for distribution and goes through a convoluted
#process to be able to distribute their videos. I asked why not get an
#exception and they told me their IT division said no exceptions
#because of the security threat such downloads would introduce.

Seems schziophrenic to have a department that produces video for
distribution as part of its work, only to have that content be ruled
verboten on the network. Nice example of non-alignment of business
requirements and security policies.

There's another point your example makes well: if you're going to
enforce content based restrictions, you need to be able to monitor
all content. End-to-end encryption interferes with content monitoring.
So enforcing content based restrictions either requires:

-- disallowing encryption (I'm sure bad guys wanting to sniff traffic
   would be delighted!), or

-- allowing holes in the content enforcement big enough to drive a semi
   trailer through (such as end-to-end encryption or use of VPNs),
   which really calls into question the whole point of doing content
   based monitoring at all IMO

#The easy way out is account lockouts which BTW ceased to be
#effective when server OS provided password control features. Early
#Unix systems (pre 1991) had NO password control mechanism so account
#lockouts were the only defense. But I digress....:-)

> From time to time I think about the password usage paradigm we have
at many sites today...

While traditionally central time sharing systems had password lockout
mechanisms, we're in a different world today. Some salient
characteristics now include:

-- a plethora of distributed password-using facilities exist (for
   example, port 587 submit to handle roaming users who'd like to emit
   email while on the road), and often, unlike traditional time sharing
   systems, the amount of scrutiny that login failures to such
   distributed password-using systems receive may be limited

-- those systems are often architected to be very high performance,
   a convenient property for badguys trying to efficiently do brute
   force attacks ("add more nodes to the cluster, the bad guys can't
   brute force us as quickly as they'd like to!" -- while I say that
   tongue in cheek when it comes to passwords, how many of us have
   done almost exactly that when it comes to building out our email
   infrastructure in order to keep up with the loads the spammers
   have imposed?)

-- requiring periodic password changes has fallen from popularity
   as a best practice, insuring that patient crackers will eventually
   get what they want even if they aren't particularly efficient

-- maximum password length and complexity rules are dancing at the margin
   of what normal humans can cope with, yet there is limited effort in
   higher education to deploy hardware tokens because of cost and other
   pragmatic factors

-- because users are overwhelmed by scores of different usernames and
   passwords, use of a single username and password for multiple
   password-protected facilities is now routine (e.g., via Radius or
   LDAP), so if you can crack someone's credentials for one service,
   such as port 587 submit, you also have their shell access or access
   to their teaching and learning system or institutional VPN access or
   dialin access or whatever

-- even if passwords are handled in a reasonably secure way, the dirty
   little "secret" that gets all too little attention is that password
   reset mechanisms very often aren't secure at all

But where's the push to fix our campus authentication infrastructures,
eh? Very basic issue, but frankly, not one that has much higher ed
"mind share" right now (at least not for basic campus-based
password-related issues, pan-institution federated identity management
and middleware are a different matter).

#I think if we sysadmin and security types ask and get answers to the 2
#questions in my point 4, we can design effective security controls
#that don't impede the business process. We need to spend the time to
#carefully analyze how the business process uses their IT assets and
#tailor the security steps to the business process instead of the other
#way around.

In some cases the business processes actually *ARE* driving security
measures, albeit in what I'd consider to be very locally optimized ways.
Consider, for example, PCI firewall requirements. The business
requirement is

  "Safeguard credit card information as mandated by the PCI standards
  so we can continue to accept credit cards for payments and so we can
  avoid the negative consequences associated with a breach of PII we
  may be handling."

Yet in working to meet that objective, how often do we overlook
"collateral damage" to other network capabilities, eh?

My point is that I would urge us to consider i) security requirements,
AND ii) business requirements, *AND* iii) long term architectural
implications of our system and network design choices.

For example, end-to-end Internet transparency (c.f., RFC2775 and
RFC4924) is a value that is all too often set aside in favor of
"more secure" NAT'd architectures in business-oriented environments.

#I now return to getting the grill ready for the holiday weekend :-).

As I was just mentioning to someone else on a call a little bit ago,
in my case I need to "hay" my little backyard so I can even *find*
the BBQ that I think is buried back there somewhere. Electric hedge
clippers can work as an improvised sickle bar mower, can't they? :-;

Hope everyone has fun and safe holidays, returning post-pyrotechnics
with all eyebrows and other flammable bits intact.

Regards,

Joe St Sauver (joe () oregon uoregon edu)
http://www.uoregon.edu/~joe/
Disclaimer: all opinions strictly my own