This page contains a Flash digital edition of a book.
Page 10


www.us-tech.com


TechWaTch Security Myths: Fixing those Leaking Holes By Jane Grafton, Director of Marketing, Lieberman Software Corp., Los Angeles, CA A


ll too often people hide behind what they “want” to believe is true. Unfortunately, personal


beliefs and opinions will not prevent a ruthless individual from ransack- ing your network’s filing cabinets. The easy road is not necessarily the secure one so, rather than wait for a hacker or malicious insider to burst your bubble, here’s what misguided individuals tell us far too frequently.


Myth One: We passed our regulatory compliance audit, so our network is safe. If we had a brick for every time we have heard this one, we could build a wall around the equator a mile thick and two miles high. Just because you passed an audit does not mean you are hack-proof. Far too many large organizations on both sides of the Atlantic are testament to this fact.


There are a number of reasons


for this. The most common is that IT departments will pull out all the stops to hit a certain number of au- dits per year, and forget about com-


pliance on all the days in between. Another big concern is auditors may not always know where to look for the holes so they can be steered in another direction. This is fair warning: hackers


won’t make an appointment to come “check” your systems! Neither will they stumble accidentally across vul- nerabilities in your enterprise. They


While some might argue that ignorance is bliss,


when an organization’s se- curity hangs in the balance remaining clueless isn’t a viable option.


know what they’re looking for and will strike on their terms. Myth Two: Our passwords change regularly in line with regulatory mandates, so our network is safe. Bad news department: this is unlikely to be an accurate statement of reality. While user login credentials


JUST ANNOUNCED Now Available in Digital Format! U.S. TECH


Every Issue Delivered Directly to Your Inbox. FREE!


Great Features:


Bookmarks, highlights, notes, forward to a friend, and more.


Coming soon: U.S. TECH on your iPAD and iPhone!


Like us on Join us on Follow us on


might be automatically prompted for change, it is the highly privileged ad- ministrator accounts that fall outside most automated solutions and there- fore rarely altered. Of course, some of you may be thinking that you’ve got that one covered because your IT staff secures these privileged identi- ties manually. All too often that sim- ply isn’t possible. While not rocket science, the sheer magnitude of the task is to blame here. Someone physically connecting


to machines, or even using scripts, to change passwords to comply with regulatory mandates is fraught with complications. Think of all the servic- es running on machines with privi- leged credentials, including any in- terdependent services, which have to be appropriately stopped before a change can be made, then restarted. It’s a daunting technical task, prone to errors, not to mention being time- and labor-intensive.


Myth Three: Our systems adminis- trators don’t share their privileged lo- gins, so our network is safe. Who are you kidding? In the real world, con- venience wins out over security. Although we are not at liberty


to name the company, a large U.S. insurance provider believed its privi- leged logins weren’t shared but soon discovered that this perception was misguided. A branch office had been given the privileged login details to resolve a routine IT administrative issue. But, since the privileged pass- word was never changed, staff at the branch office were free to change set- tings on their machines and install software at will for many months. And this wasn’t an isolated case. Others within the organization had also been given these “keys” to the network, and had gone on to share them with more employees, allowing the spread to creep around the entire enterprise.


Myth Four: Our IT team knows who has access, so our network is safe. Okay, this one has a couple of threads to unravel. Passwords for highly privileged


accounts are often hardwired into ap- plications, or given to contractors and outsourcers to use. Because these logins are shared it’s impossi- ble to pinpoint exactly who, or even what, is behind the connection. Simi- larly, as we’ve already alluded, these passwords rarely change, meaning someone who is no longer employed or contracted by the organization could hijack these credentials and gain access. In the case of administrative ac-


The Nation’s Hi-Tech Electronics Publication


Subscribe today: www.US-Tech.com See us at Semicon West / Intersolar Booth 6376


counts, these exist in droves and, again, they too get shared. Because everyone uses the same common cre- dentials to get into a machine and


make changes at a highly privileged level, you never really know who is responsible for alterations, or even has had access to sensitive data. A final issue is people changing


job roles within the organization. If their credentials haven’t been changed then they may still have ac- cess to information or services that they no longer need.


Myth Five: Our existing Identity Ac- cess Management software is control- ling users, so our network is safe. This is a common misconception. As we’ve already said, most organizations have no processes to control highly privileged administrator logins typi- cally used for emergency firecall or routine administrative access. To spell it out, all existing secu-


rity solutions — firewalls, IAMs etc. don’t track and control privileged identities. The truth is that, unless it’s a specialized solution, it can’t! Now, how many of you thought


you were safe prior to reading this? While the majority of organizations are ignorant of the reality of the se- curity within their enterprises, igno- rance is not an excuse, and will not prevent your systems from being breached. Instead, regain control of your enterprise by following these five rules: l Don’t focus purely on passing an audit. Instead remember that your end goal is continuous compliance. You can achieve positive results by viewing each potential security hole as something to investigate and mit- igate rather than a crack to be pa- pered over. l Ensure that all default passwords are changed before deploying any new devices or programs in a net- worked environment. This can be easier said than done, as there could be more published default logins and developer back doors on your net- work than anyone might know. lConfigure all privileged accounts to require password changes every 60 days at the most, using unique, com- plex passwords for each account in the network. l Store all passwords in an encrypted format, only accessible with delegated and audited super-user privileges. l Employ automated tools that will inventory all privileged accounts, monitor for anomalous behavior, au- dit all activities and control their management consistent with the FD- CC (federal desktop core configura- tion) standard. Contact: Lieberman Software


Corp., 1900 Avenue of the Stars, Suite 425, Los Angeles, CA 90067 % 800-829-6263 or 310-550-8575 fax: 310-550-1152 E-mail: info@liebsoft.com Web: www.liebsoft.com r


July, 2012


Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16  |  Page 17  |  Page 18  |  Page 19  |  Page 20  |  Page 21  |  Page 22  |  Page 23  |  Page 24  |  Page 25  |  Page 26  |  Page 27  |  Page 28  |  Page 29  |  Page 30  |  Page 31  |  Page 32  |  Page 33  |  Page 34  |  Page 35  |  Page 36  |  Page 37  |  Page 38  |  Page 39  |  Page 40  |  Page 41  |  Page 42  |  Page 43  |  Page 44  |  Page 45  |  Page 46  |  Page 47  |  Page 48  |  Page 49  |  Page 50  |  Page 51  |  Page 52  |  Page 53  |  Page 54  |  Page 55  |  Page 56  |  Page 57  |  Page 58  |  Page 59  |  Page 60  |  Page 61  |  Page 62  |  Page 63  |  Page 64  |  Page 65  |  Page 66  |  Page 67  |  Page 68  |  Page 69  |  Page 70  |  Page 71  |  Page 72  |  Page 73  |  Page 74  |  Page 75  |  Page 76  |  Page 77  |  Page 78  |  Page 79  |  Page 80  |  Page 81  |  Page 82  |  Page 83  |  Page 84  |  Page 85  |  Page 86  |  Page 87  |  Page 88  |  Page 89  |  Page 90  |  Page 91  |  Page 92  |  Page 93  |  Page 94  |  Page 95  |  Page 96  |  Page 97  |  Page 98  |  Page 99  |  Page 100  |  Page 101  |  Page 102  |  Page 103  |  Page 104