Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Security Operating Systems Software

Is Whitelisting the Answer To the Rise In Data Breaches? 195

Posted by timothy from the none-shall-pass dept.
MojoKid writes "It doesn't take a rocket scientist to figure out that cyber criminals are quickly getting more sophisticated than current security, intrusion detection and prevention technology can defend against. And you have to wonder if the computer security industry as a whole is willing to take the disruptive measures required to address the issue head-on. One way to tackle the surging data breach epidemic is with a technology called "whitelisting." It's not going to sound too sexy to the average end user and frankly, even CIOs may find it unfashionable but in short, whitelisting is a method of locking-down a machine such that only trusted executables, DLLs and other necessary system and application components are allowed to run – everything else is denied. A few start-up security companies are beginning to appear in this space. The idea is to start with a known, clean system installation and then lock it down in that state so absolutely nothing can be changed. If you follow system security, regardless of your opinion on the concept of whitelisting, it's pretty clear the traditional conventions of AV, anti-malware, intrusion detection and prevention are no longer working."
This discussion has been archived. No new comments can be posted.

Is Whitelisting the Answer To the Rise In Data Breaches? More

Is Whitelisting the Answer To the Rise In Data Breaches?

Comments Filter:

  • "whitelisting" (Score:5, Funny)

    by Anonymous Coward on Sunday February 09, 2014 @05:10AM (#46201195)

    Yes, yes, tell me more about this novel concept, I have never heard of the term before

    • Re: (Score:2, Redundant)

      by mrbluze ( 1034940 )

      Problem: Data Beaches

      Reaction: Whitelisting

      Solution: Censorship

      And by the way, Beta sucks.

      • Re:"whitelisting" (Score:5, Insightful)

        by anubi ( 640541 ) on Sunday February 09, 2014 @08:58AM (#46201947) Journal
        A LOT of us are doing a form of whitelisting for exactly the same reason.

        How many of us are running programs similar to NOSCRIPT mostly because of hostile code and inattentive webmasters unwittingly distributing malicious code wrapped in advertisements?

        I learned about NOSCRIPT right here on Slashdot ( Thanks, guys!!! ) in response to one of my posts where I was whining ( loudly ) about not being to be on the net for more than a few hours before I had to reboot Windows to try to get my system back.

        There is a lot of nasty stuff out there, and it seems most of it comes riding in on scripting or coaxing me to run their attachment. Often I have seen them try to piggyback on the trust I have for a business - a business that places that trust at risk if the business insists I enable javascript for his site, then the bad guy uses that coercion of the business model to his own advantage.

        I think that is what a lot of the clamor here has been all about. We see wealthy investor type men taking control from the techie base and may force us to "drop our defenses" in order to communicate, and we are collectively screaming "NO" as loud as we can to the deaf ears of the businessman.

        I think we have all seen the suit people take down a business, and we don't want it happening here.

        • "How many of us are running programs similar to NOSCRIPT mostly because of hostile code and inattentive webmasters unwittingly distributing malicious code wrapped in advertisements?"

          Generally speaking, NoScript is blacklisting, not whitelisting. Although you can whitelist programs in NoScript to prevent them from being blacklisted. :)

          Newer versions of OS X use whitelisting by default, for unsigned executables.

    • Re:"whitelisting" (Score:5, Insightful)

      by Z00L00K ( 682162 ) on Sunday February 09, 2014 @06:14AM (#46201437) Homepage Journal

      Most data breaches have occurred within a company, and the only way around it is to segment the networks and servers so that only select computers have access to financial data, others have access to HR data and yet others have access to strategic documents. Then it depends on company type if yet more segments are needed. In most cases the software development can go in one segment - the majority of the software developed is bread&butter. But in other cases special projects may need their own segment. Also make sure that all printers have their own sub-segment of each segment to make sure that any printer that has been hacked isn't going to have access to all the data, just the print data.

      Of course - this goes against the strategy of installing everything in one huge server running virtual servers.

      Whenever there is a need to exchange data it has to require manual action between individuals in both segments.

      And for browsing the internet - run a sandbox solution to isolate any browsing from the remaining network. It may mean that the web browser is on a special server. If that server is contaminated it's not a big problem to rebuild it.

      • Re: (Score:2)

        by tramp ( 68773 )
        Installing everything in one huge server running virtual servers should make it easier by creating virtual network segments. And even with such segments it is questionable if the potential damage in one segment is not a reason to whitelist within each networksegment too.

        • Unfortunately, though it's relatively rare, vulnerabilities allowing software to "escape the virtual machine" are not unheard of. For the kind of security model we're talking about here, you ought to be running isolated segments on completely separate physical systems that can communicate only via controlled channels with suitable safeguards like firewalls and DMZs in place, if they even need to communicate at all. Basically, each segment in your network should regard traffic from any other segment as poten

      • Think of the average level of intelligence - 50% of the population are stupider than that! (Some say not all of them are PHB's, but I have yet to see the evidence;-)

        • Re: (Score:2)

          by DarkOx ( 621550 )

          Think of the average level of intelligence - 50% of the population are stupider than that!

          Intelligence is hard to come by, as evidenced that even on Slashdot so few have even a basic graps of statistics. It also explains why the pols can get away with so much...

    • Re: (Score:3)

      by drolli ( 522659 )

      O, i wish i had mod points....

      I always thought that the "x" bit under unix was a kind of whitelisting mechanism (in combination with the "noexec" mount option).... or the security contexts under Windows or Apparmor or SELinux

      But now, there is a new startup which wants to promote a product...

    • "Yes, yes, tell me more about this novel concept, I have never heard of the term before"

      Of course you didn't know about them before. You even missed the basic point that it is not a concept but a "technology". It is said right there, in the article!

      I for one will immediately buy a score of units of this new technology!

  • Brilliant... (Score:1, Insightful)

    by Anonymous Coward

    ... next we'll make it impossible to emulate a trusted DLL ... oh, wait.

    • Re: (Score:3)

      by mikael ( 484 )

      There was a guy at our university wanting to do some university psychology tests and figured the best way for the application to log the results was to send them as an E-mail to himself, where they could be timestamped independently. Only problem was that any application that wasn't on the PC's anti-virus whitelist was blocked from opening that port. So he just renamed his experiment application to "Agent.exe" and the anti-virus software allowed the message to be sent.

    • I am sure the white list contains the hash of the all the items.

      • Re:Hash (Score:4, Informative)

        by Predius ( 560344 ) <.josh.coombs. .at. .gmail.com.> on Sunday February 09, 2014 @10:58AM (#46202487)

        Exactly. Windows has a means of doing this built in from at least XP, but no app provided to automate it's management. You can setup the system so it will only execute binaries with approved hashes. Back around 2002/2003 we were playing with a program in house that would build a baseline of approved hashes on a clean system, then push that list out to our workstations. To get an app approved we would then fire up the clean box, install, update, push, etc. We never got it past the budget phase though, but it accomplishes exactly what OP is asking about. For point of sales terminals, etc that shouldn't be a moving target I'd say heck yes they should be in whitelist only mode.

        • System file checker (sfc) is a means of this isn't it?

          If so, I believe that has been around since windows 98se and is intended to be administered by MS online updates after the initial instal. It's not terribly useful for files outside of windows core files though. but it is a pretty good check after a virus or malware removal to at minimum ensure you can get into an uncompromised safe mode to search for infection remnants.

        • Re: (Score:2)

          by thogard ( 43403 )

          Microware OS-9 from 1979 used program and modules somewhat like DLL or shared libraries. The code to load a module would CRC check them when loaded and that bit of code could check a list and that list could either allow or deny any module. If you loaded the right data module, you had built in white listing about 3 and a half decades ago.

  • What is someone breaks in, gets command line access and uses trusted commands to send the data elsewhere. The hacker used trusted programs to do the breach so white list would not stop it.

    • Re:Trusted program, untrusted use (Score:5, Informative)

      by Tom ( 822 ) on Sunday February 09, 2014 @06:41AM (#46201519) Homepage Journal

      All good security is layered. This is one part of a complete security model, the part that prevents the hacker from uploading and using his own tools.

      Of course, you also need other parts. For example, runtime-patching is a reality, so unless you have additional protections in place to prevent it, there are plenty of ways that a hacker can still execute arbitrary code including entire programs.

      But the primary protection this offers is to finally solve the exe-cloaked-as-jpeg-or-zip-in-a-scam-email-that-users-click-to-open problem that Mickeysoft should've solved 10 years ago by simply fucking removing that idiocity from Outlook one day after it went live and people realized how trivial it is to abuse.

      Basically, the primary beneft of this will be that it prevents unintentional execution of code. It doesn't stop a dedicated attacker who already has root access, at least not by itself.

      • Comment removed (Score:4, Interesting)

        by account_deleted ( 4530225 ) on Sunday February 09, 2014 @07:54AM (#46201741)
        Comment removed based on user account deletion

        • Re:Trusted program, untrusted use (Score:5, Insightful)

          by Tom ( 822 ) on Sunday February 09, 2014 @10:34AM (#46202373) Homepage Journal

          Oh please do you REALLY think that is the cause of Windows infections?

          Your reply was misplaced by the comment system, it seems, because it doesn't seem to refer to anything I actually said.

          The social engineering angle is how you get users to execute crap they got sent by mail. The (old) idea under discussion here is a system that would make that execution impossible, even if you get the user to click the link.

          That said, the user is not the weakest link. That's a cop-out by IT people who don't want to look beyond technical solutions into cognitive sciences, for example. There's been a bit of research into these areas in the past 10 or so years, but the conferences on the topic are still very small and mostly academic.

          There's quite a lot you can do to prevent or at least make these kinds of attacks more difficult. But most of it is outside the techie comfort zone, and it means actually having to talk to users and understand them instead of labeling them "lusers" and stuff.

      • Re: (Score:3)

        by fermion ( 181285 )
        10 to 15 years ago MS tried. That is why so many companies have the IE/Outlook lock in. It was supposed to be secure. In many ways it was, using whitelists. Certain things could not be sent over Outlook. IE would keep certain things from running. You could set permissions and proxies and the like. Everytime a user logged in scripts could be downloaded and run on local machines to set new security regimes.

        This worked in limited cases, but not in business where workers are not volunteers, time is ab

    • What is someone breaks in, gets command line access and uses trusted commands to send the data elsewhere. The hacker used trusted programs to do the breach so white list would not stop it.

      Well your machine is now compromised. You now have to ask the question "What can I do". Normally in a case like this you should do a fresh OS install from a trusted source (eg. bootable CD/DVD, USB key) followed by appropriate customisations then updates from a trusted source. You could do a recovery from your OS backup but if you have been compromised I would not trust this.

      Obviously you may need to recover your user data if that has also been compromised but if are looking at an enterprise system or eve

  • Licensing and Cert Costs (Score:3, Interesting)

    by Anonymous Coward on Sunday February 09, 2014 @05:30AM (#46201291)
    It's too expensive. If you operate in a Windows environment then you have to use Windows Enterprise to access the functionality (which is expensive) and since code-signing certs are expensive not many devs (including driver devs) use them, meaning, you have to go back to file hashes for individual versions for files that aren't signed. We use these mechanism at my work for high risk workstations and the workload of maintaining them is quite tedious. We just aren't there yet as an industry.

    • Windows can be made to boot of DVD or read only media.

      Now to also make %TEMP% with no execute allowed.

    • I haven't had the... pleasure... of having to deploy it, just poked around; but won't the Windows SRP signature-based rules work just fine if you create your own internal certificate, bless it, and then sign anything you want to run; but don't have a publisher signature for?

      Doesn't do you much good if you don't know what you are signing, or something gets munged on its way from the vendor to IT; but you don't have to tithe to verisign if the machines are on your domain and will trust you as a CA if you t

  • Seriously? (Score:5, Insightful)

    by gman003 ( 1693318 ) on Sunday February 09, 2014 @05:32AM (#46201295)

    Why the flying fuck does anybody think Slashdot readers need to have "whitelisting" defined for them, let alone think they can pass it off as a "new technology"? Did Dice start putting those retarded SlashBI articles in main Slashdot now?

    • Re:Seriously? (Score:4, Funny)

      by Anonymous Coward on Sunday February 09, 2014 @05:50AM (#46201367)

      As a manager these definitions really help me out. Could you tell me if these 'whitelistings' are webscale?

      ps I really like the new slashdot beta site!

      • I'd mod you up, but duuuude, 'webscale' is sooo yesterday.

        Leveraging your core value proposition thru social networking in the cloud is the new hotness!!!

        I really dig the new beta site too - liked it on all my facebook pages and tweeted it too!

        Now 'scuse me, have to update my whitelists and hosts files.

    • Re:Seriously? (Score:5, Insightful)

      by TheReaperD ( 937405 ) on Sunday February 09, 2014 @05:55AM (#46201387)

      Though most, if not all of us, know what whitelisting is, I do prefer they explain it rather than assuming we know it. I've ran across too many articles in the past that assumed I knew some piece of information when I didn't. Sure, I can look it up but, that's annoying when your just trying to read "news." Though this is a site for "nerds", that is a broad term. There's computer nerds, science nerds, comic nerds, etc. Now, the passing it off as new... I've got nothing; that's just lame.

      • The way some sites handle this is by using the dfn element (or abbr) to actually explain what a term means or expands to. The regular reader just sees the term, but (typically) hovering over it will show the full definition / expanded form. That has always seemed like fair compromise to me.

    • Re:Seriously? (Score:5, Insightful)

      by Anonymous Coward on Sunday February 09, 2014 @05:57AM (#46201397)

      Uh, yeah. The sort of dumbfuck managers who might conceivably read slashbi are the exact audience the beta design (fuck beta, BTW) is meant to appeal to.

      The big idea, though unspoken, is clear: to keep the slashdot name, but shift in both content and presentation from a discussion site seeded with news for nerds to a straight-up news site (with discussion as an afterthought) for PHBs. SlashBI doesn't work because that name is not (and has never been) perceived to carry an aura of technical knowledge -- but PHBs have been hearing about this slashdot thing for a decade now. Rolling out a PHB-friendly site under the "slashdot" brand will help PHBs play one of their favorite games, namely indulging in the fantasy of deep technical knowledge without the inconvenience of learning -- and that means Dice makes big bucks placing ads in front of this "decision maker"-heavy audience. (This new audience is not only worth more to advertisers, they're also substantially less likely to use ad blockers than the old /. community.)

      • Re: (Score:2, Redundant)

        by kevingolding2001 ( 590321 )
        Please, anybody with mod points, mod the parent up.

        Yes I know that he or she is posting as AC, but this so beautifully encapsulates where the 'beta' is headed that it really deserves to be seen.

        The original slashdot users and discussion format simply don't fit into the 'passive content consumer' business model of dice, and no amount of posting 'fuck beta', or boycotting, or whining to Timothy or any of the other editors is going to change that.

    • Re:Seriously? (Score:5, Insightful)

      by Arrogant-Bastard ( 141720 ) on Sunday February 09, 2014 @08:04AM (#46201765)
      The inferior people at Dice -- you know, the same ones trying to shove their shitty Beta site down our throats -- are actually not clueful enough to realize that this is a very old idea. Whitelisting OS resources, applications, networks, IP addresses, etc. has long been an effective security measure, and I've deployed everywhere I've been for the past 15 years or so.

      It appears that the Dicedroids think everyone is as stupid and clueless as they are.

  • Already Possible (Score:5, Interesting)

    by EmperorArthur ( 1113223 ) on Sunday February 09, 2014 @05:41AM (#46201329)

    Newer versions of Linux can already do this. Using the integrity measurement architecture, module signing, and Secure Boot it's possible to have a system where almost any change is detected. I'm currently trying to get it all working on my machine right now, but it's slow going. Here's hoping that distros start shipping with this set up by default. http://lwn.net/Articles/488906... [lwn.net]

    A shorter term security measure that more users/Distributions should take is making the root partition read only. I know Android already does this, but it really does help. Something that I would really like to see is an easy to use per application firewall. Cgroups mean that I don't even have to worry about it just spawning a child process. Yes, I want to play this game in wine. No, I don't want it to access the internet. No, wine refuses to run it as a different user, much less one with lower privileges.

    • Newer versions of Linux can already do this. Using the integrity measurement architecture, module signing, and Secure Boot it's possible to have a system where almost any change is detected. I'm currently trying to get it all working on my machine right now, but it's slow going. Here's hoping that distros start shipping with this set up by default. http://lwn.net/Articles/488906 [lwn.net]...

      A shorter term security measure that more users/Distributions should take is making the root partition read only. I know Android already does this, but it really does help. Something that I would really like to see is an easy to use per application firewall. Cgroups mean that I don't even have to worry about it just spawning a child process. Yes, I want to play this game in wine. No, I don't want it to access the internet. No, wine refuses to run it as a different user, much less one with lower privileges.

      Take it from a former Solaris admin, difficult to maintain over-engineering is not the answer. It will fail, and users will hate you.

      Question of the day: Why are single user smartphone OSs better at segregating processes than server OSs in the first place? Even while using basic UNIX features to do it?

      These classic UNIX systems kind of need to roll over and fall into their graves already. I mean look at what you get with VMWare ESX, then look at iOS/Android, then look at say.. a RHEL-type classic UNIX se

      • It's relatively easy to get those features if you don't mind breaking all backwards compatibility. Which is what Android did.

        It gives each separate process it's own UID, but has them all using a common display server. Then you combine the way that almost everything has to be done through the android framework with some special kernel patches. For instance, /etc is normally used for settings files, but that means special things have to be done if you want to mount root as read only. Especially since some

  • NetBSD can do this already (Score:5, Informative)

    by Anonymous Coward on Sunday February 09, 2014 @05:41AM (#46201331)

    http://netbsd.org/docs/guide/en/chap-veriexec.html
    Veriexec is NetBSD's file integrity subsystem. It's kernel based, hence can provide some protection even in the case of a root compromise.Veriexec works by loading a specification file, also called the signatures file, to the kernel. This file contains information about files Veriexec should monitor, as well as their digital fingerprint (along with the hashing algorithm used to produce this fingerprint).

    • Re: (Score:2)

      by mysidia ( 191772 )

      Veriexec is NetBSD's file integrity subsystem. It's kernel based, hence can provide some protection even in the case of a root compromise.

      Although.... the JunOS routers which are based on FreeBSD use veriexec. Upon boot, after mounting filesystems; the devices set veriexec to level 3 and increase the securelevel to 1.

  • Please read before modding down. (Score:4, Informative)

    by Anonymous Coward on Sunday February 09, 2014 @05:45AM (#46201345)

    What company directs 25% of its users to a partially-working, not-ready-for-production website? Please realize that Beta will not have the features that we want, because it goes against Dice's plans for Slashdot. To their advertisers, Dice presents Slashdot as a "Social Media for B2B Technology" [slashdotmedia.com] platform. B2B - that's the reason Beta looks like a generic wordpress-based news site. A large precentage of the current userbase might be in IT, but /. is most certainly not a B2B site.

    Nevertheless, Dice is desperate to make money off of Slashdot, since it has not lived up to their financial expectations, a fact that they have revealed in a press release [diceholdingsinc.com] detailing their performance in 2013:

    Slashdot Media was acquired to provide content and services that are important to technology professionals in their everyday work lives and to leverage that reach into the global technology community benefiting user engagement on the Dice.com site. The expected benefits have started to be realized at Dice.com. However, advertising revenue has declined over the past year and there is no improvement expected in the future financial performance of Slashdot Media's underlying advertising business. Therefore, $7.2 million of intangible assets and $6.3 million of goodwill related to Slashdot Media were reduced to zero.

    Beta is not a cosmetic change. It is a new design that deliberately ruins the one thing that makes /. what it is today -- the commenting system. There is nothing wrong with Slashdot, from the users' perspective, that demands breaking its foundations. As others have commented, this is an attempt to monetize /. at any any cost [slashdot.org], and its users be damned. Dice views its users, the ones who create the site [slashdot.org], as a passive audience. As such, it is interchangeable with its intended B2B crowd. We, the current users of Slashdot, are an obstacle in Dice's way.

    That is why they ignore the detailed feedback they have received in the months since they first revealed Beta. That is also why they now disregard our grievances. Their claims of hearing us are a deliberate snow job. It is only pretense, since at the same time they openly admit that Classic will be cancelled soon [slashdot.org]:

    "Most importantly, we want you to know that Classic Slashdot isn't going away until we're confident that the new site is ready.

    Don't hold your breath waiting for Dice to fix Beta. Their vision of Slashdot is a crippled shadow of the site as it is today. Don't let them pull the wool over your eyes. Dice doesn't need us, and it wants us out.

    Slashdice delenda est!

  • Better idea (Score:3)

    by thegarbz ( 1787294 ) on Sunday February 09, 2014 @06:07AM (#46201417)

    Why not just take computers away from people? I mean if you're going to put such heavy restrictions in place why not just give someone pen and paper, it would be equally as efficient for the end user than having to call up IT every 5 minutes because you're not allowed to use the computer you're given.

    • Re:Better idea (Score:4, Interesting)

      by Tom ( 822 ) on Sunday February 09, 2014 @06:37AM (#46201511) Homepage Journal

      Because their productivity will higher with a computer, even a restricted one, than pen-and-paper. And if you are talking typical office workers, you would be surprised how few applications they actually need. Most of the office workers in the world spend 99% of their time in

      • an office suite
      • a mail program
      • a browser
      • a single-digit number of job-specific applications (e.g. the accounting software)
      • and maybe a single-digit number of company-specific applications (e.g. the time registration app or the intra-company chat software, etc.)

    • it would be equally as efficient for the end user than having to call up IT every 5 minutes because you're not allowed to use the computer you're given.

      Actually, you are permitted to use the computer for what it was assigned to you for. What you cannot do is run all sorts of executables which have not been approved, some of them being malware, stupid browser plugins and all kinds of crap.
      The company I work for have implemented bit9 on the XP PCs we need to keep. Works just fine. The user can keep the software that cannot run on 7/8, and the computers are secure.

    • Re: (Score:3)

      by jon3k ( 691256 )
      I think you have to consider the type of business. I work in healthcare and there are only a couple of applications they need to run. We lock down those applications on windows desktops using Software Restrictions [microsoft.com].

      Seriously consider, how often do you need to run a NEW application? Every 5 minutes? Really? Do you think most organizations don't have a list of approved applications that have been vetted through a security process and are maintained and updated by IT?

  • old idea (Score:4, Insightful)

    by Tom ( 822 ) on Sunday February 09, 2014 @06:33AM (#46201489) Homepage Journal

    The idea is one of the oldest in IT security.

    And it works really, really well.

    And it is a PITA to administrate if you have a system that changes, as lots of systems do. For your regular service server, much less a desktop system, where new releases require new libraries, system updates are regular and new application required every now and then, it is almost impossible to actually do it.

    On a locked-down system that needs to do one thing, but do that thing reliably and securely, it's a fantastic security measure that will eliminate about half of your security headaches right there.

    It's the same idea as SELinux, just on a different level, and it shares many of the disadvantages, namely that it makes policy management into a full-time job.

  • We're adopting this at work... (Score:5, Insightful)

    by Dr_Barnowl ( 709838 ) on Sunday February 09, 2014 @07:04AM (#46201581)

    While I admit that as a programmer I will inevitably have a skewed point of view, I view it as ill-advised.

    A computer is useful primarily because it is NOT a special purpose tool, but a general purpose one.

    Whitelisting cripples your computer. If you can't run software without it being on a whitelist, you can't even write a shell script, or a VBA macro. Your computer stops being useful as a general purpose tool - only the software that has been approved remains useful.

    Yes, I get that most users are numpties and probably do need to be kept from hurting themselves. But this kind of policy cuts down the tall poppies - the ones who actually can make their computer work for them, instead of just working at their computer, and removes the possibility that any more will arise - no-one will voluntarily seek the rights they need to approve of their own software, because they'll be singled out as potential hackers and troublemakers, and any data breaches that do occur will be attributed to them.

    As applied within our organization, it's also soul-crushingly annoying to programmers. We'll have the rights to approve of any software we want to run, but we have to click through an approval dialog for each... new..... file... which of course, means that every time we rebuild our code we face a clickfest just to debug it, or run unit tests on it, etc.... most of us have shied away from being "upgraded" to Windows 7 because of this. Several of us just wish we could change to Linux, being Java programmers.

    Indeed, many of our internal teams are also getting the self-approval rights, which just trains them to click "Approve" and you're all the way back to UAC again, no extra security, just extra hassle, reduced performance of the computer (which is now hashing every file you access on the drive to see if it's on the whitelist), and more money diverted into the coffers of the kind of company that sponsored this story in the first place.

    • This idea is for computers hosting credit card info, personal information, and other potential targets. A development environment may host interesting bits, but should never have these tempting bits on it.

      Your implementation is everything whitelisting was never intended to be, and is unrelated to this story except tangentially as a cautionary tale of where to draw the line as an employee.

      I don't see how whitelisting on a POS device will possibly work if it needs updates, delivered remotely, and whitelist up

      • The software running on the POS is completely known and controlled. In a big organisation there are lots of them, so you want to be able to update over the network. Updates are tested and bundled with any whitelist updates required. It's the perfect environment for whitelisting.

        I'm curious why think it won't work on a POS with remote updates?

    • Re: (Score:2)

      by jon3k ( 691256 )
      Many verticals have a specific set of approved applications. Finance, healthcare, legal, manufacturing, etc. They don't need to randomly run anything they have a very small set of approved and vetted applications. Whitelisting works in a very large number of instances.

  • Whenever someone tells you that x solves all problems, it typically doesn't.

    Whitelisting is currently practised on many mobile platforms. The only thing it does is force people to turn it off so they can actually use their devices, since the white list was done by people with differing opinions.

    The more sensible solution is to do it like Debian does it. Have repositories making it easy to download software which matches certain criteria. Make it moderately hard to install new repositories and make it hard t

  • It's not that those methods do not work, it is that the managers, executives, and directors are insulated from the damage. Make the CIO, CFO, and CEO cough up a few million per breach and they will be stopped. Close companies that are breached repeatedly, and make the directors reimburse the other stockholders out of their own pockets. I once worked at a company where the CEO mandated that he should be able to access confidential information at any location in the company, including offshore locations.

  • No. (Score:5, Insightful)

    by gweihir ( 88907 ) on Sunday February 09, 2014 @08:02AM (#46201755)

    As usual with this type of headline, this is not a solution. In fact, it is not a solution at all. Just think of the most common way to compromise an executable: Buffer overflow. In that case, code is put somewhere in the memory area of the running process and then the process is coerced to execute it. This means the attack code runs in the context of the already running process afterwards and white-listing has zero impact. The only effect it has is that it gets harder for the attacker to start additional processes.

    As for code-injection attacks, these are usually done with interpreted code, and white-listing does not even apply to that.

    This is another technology that at best makes it harder for script-kiddies to break into a system, but has basically no impact on competent attackers.

    Incidentally, techniques like SELinux allow far more than a simplistic "white-listing", and have done so for quite a while.

    • Re: (Score:2)

      by jon3k ( 691256 )

      Just think of the most common way to compromise an executable: Buffer overflow.

      You're asking the wrong question. The real question is what's the most common way to compromise a Windows COMPUTER. And that answer is to trick the user into running an untrusted piece of software, either from some web page (using some browser or extension bug, or convincing them to download it) or via an e-mail attachment.

      • Re: (Score:2)

        by gweihir ( 88907 )

        No, I do not. There is no need to compromise the computer today, compromising an application is quite enough for most purposes these days. One of the downsides of putting a web-interface on everything.

        Of course, ultra-low cost and competence attacks like the ones you describe are an issue, but only for organizations that really, really have no clue how to manage IT security. How such organizations would manage to administrate a "white-list" is unclear, likely they would just botch it as well.

  • The powers that be had the great idea of launching a policy of locking down PCs where I work. Which is ridiculous considering that we're a large research university and that, believe it or not, bureaucrats can't predict what researcher X in lab Y will want to put on their computer. Because users were unable to do anything on their own, the IT people were spending a lot of time going from one office to the other installing the software that people needed. It lasted for maybe a week, at which point some "help

  • No. Getting your mom to show you how to use the washing machine is the answer to dirty britches.

  • A buffer overflow should not provide the keys to the city.
    We need security orthogonal to the executing application surface.
    Here's an idea, don't know if it will catch on but how about
    encrypting the data in it, whitelisting the users / apps that can use it, thereby
    reducing the
    surface vulnerable to attack. It would require a sophisticated public key
    infrastructure integrated
    with all processes. Data objects could organize their fields into multiple segments that can be origressively unlocked.

  • now. This is hardly a new concept or a new implementation.

  • Java (Score:2)

    by gmuslera ( 3436 )

    You still have to apply security updates to your installed software, specially with the lot of remote java vulnerabilities that had been disclosed in the last year (and that you should had been hurried to fix). And you must trust in who send you your update to whitelist it, because it could be someone playing MITM.

    In the other hand, whitelisting an approved by some authority list of software means that the only software you will be able to install is the already backdoored by government ones, and perpetuat

  • For routine operation of Internet-exposed systems, the / (which includes /usr and, usually, /usr/local) mounted read-only. The user-modifiable places (/home, /tmp, /var) are mounted with the noexec option.

    Although a dedicated attacker might be able to succeed anyway (the same script can be run with a sh script instead of ./script), it throws sort of a "tangle-foot" over them — most of the hacks involve some compiled binaries. And, if the targeted filesystem is mounted read-only, even root can not mod

    • Re: (Score:2)

      by jmauro ( 32523 )

      Back in the days when you could get regular CD-ROM drives I saw some setups that would put /usr, /usr/local and /opt on a CD-R and then boot of the CD. Since the drive couldn't write even trying to force a reboot to mount RW was pointless since the drive couldn't physically write to the drive.

      The down side was it was a pain to operate like that since every patch required a new CD to be burned. Most gave up after too long once they realized how often they'd need to be patching thing.

  • Why not have a no cost public registration process for anybody who wants to write an trustworthy executable program. Issue a certificate for each individual developer who is added to the list of contributors for a trustworthy program. Make it voluntary. If you want to develop or run anonymous or old software - go right ahead - you've been warned so you can be careful.

    *All* execution environments would need updates to support this so it won't be easy or quick. This is not a new idea, but having it populari

    • One big problem is that there are a tremendous amount of things that are executables. They're not just compiled executables or Javascript, but anything that might be run through an interpreter. We've had VBA viruses for a long time; should we have to register Word documents before passing them around? Suppose I send you a registered Perl interpreter and a malicious Perl program? There's malware in places most people never expected.

      Another is simply setting up the registry. To do any good, there woul

      • No question - its a *huge* job, but unfortunately we have to start. We probably cannot retrofit this into old stuff - it has to be inherently baked in to future execution environments - especially operating systems and web browsers.

        Its gotten so bad with VBA that Word now makes you OK the execution environment when you open the document. Presumably classes of programs like the Perl interpreter would potentially be risky software that requires an OK to run at all. Same thing with shell scripts.

        You would
  • So, sure, whitelisting might prevent your uses from running unapproved browsers at work, but it will not secure a computer system against actual attackers. Not to mention that a good chunk of would-be whitelisted binaries actually have embedded language environments (macros, javascript, shell/batch scripts, java, vbscript, etc.) that would also need to be added to the whitelisting framework.

  • Whitelisting works against a lot of things. It doesn't work against things that look enough like the program to sneak through or against hack systems that are outside your system probing for weaknesses.

    Not only do you need a white listing system you need portions of the network that are hardcoded. Literally impossible to change because the coding is set in stone. You can have firmware in those systems but the firmware has to be READ ONLY. Possibly you could have a PHYSICAL switch that enabled read/write to

  • I just figured out how to turn on the Administrator account on Windows 7 & knock everyone else down to Standard! O:

  • A simple shell script runs only resident binaries, and it can already do a lot of harm. It can even escalate using local exploits.

    How can whitelisting help here?

  • This article appears to me to be an advertisement placement article. The technology is not new, and hence not 'start up companies', except the one they are pushing. The technology is built into Windows but has no useable interface. stupid of Microsoft to leave that to the user and say nothing while maleware and hacking goes rampid. It is however good however to see the best solution get more attention. The AV track is a loosing proposition right out of the gate if you are the target of a hacker. My compan

Slashdot Top Deals

The use of money is all the advantage there is to having money. -- B. Franklin

Close