finding revlet limits in a controlled environment

[Phil Davis]

I'm answering my own question - see below. Maybe it will answer 
questions that come up in your world.

Phil


Phil Davis wrote:
> Hello -
>
> My client wants to sell revlet-based software to his customers in a 
> large US govt agency. If they are able to download & install the 
> revweb plugin, we don't know what limitations to a revlet's 
> capabilities might be enforced by IT in their computing environment. 
> To answer this question, we've built a web site his customers can use 
> in their world that steps them through a series of revlets that each 
> try different kinds of activity. The activities include:
>
>    * load the plugin and do nothing
>    * create, read, rename, delete a file on the local HD
>    * get a web URL (google.com)
>    * run a shell command ("dir" or "ls")
>    * create, delete a stack in memory; get a stackfile from a web server
>    * print to their printer
>
> Those are all the tests so far. The test web site emails the revlet 
> test results back to me.
>
> Now my question:
> Are we testing the right things? If not, what else should we test for?
>

Here's a response from an off-list, non-Rev-user, IT network security 
friend of mine:

> As for what apps can/can't do in any, or large enterprise sized 
> environments, is going to depend on several things... you can be 
> assured of one thing: federal systems, and even state organizations, 
> are getting locked down tighter and tighter all the time. Local 
> installation is probably going to have to go thru if the app is a 
> local install that will probably be the most difficult to get running 
> 'vanilla' in anyone's environment with the level of security and 
> access controls put on local systems and lock down of the registry. 
>
> Here's what you can probably count on:
> 1) full read/write from and to the users' My Document and temp space.
> 2) outbound connections on port 80 and 443 (SSL v3 or TLS)
> 3) no inbound connections allowed
> 4) be prepared to illustrate the application/web tool security from a 
> security scanner report (Nessus is a great open source tool that is 
> kept up to date for vulnerabilities and provides risk mitigation 
> instructions).
> 5) If the app/tool wants any elevated privileges and it will be run by 
> the general user, probably is not going to be approved.
> 6) Every organization has (or not) its own security posture and 
> policies. Those organizations with CISSP (Certified Information 
> Systems Security Professional) don't always mean they are technical 
> and may have to pass the review/approval down to frontline 
> administrators with specific security skills. I've seen managers 
> without any technical, let alone systems security expertise, get the 
> CISSP cert and throw it around like they're the best thing since 
> sliced bread....(all you have to do is mentions something about ports, 
> proxy or routing and they will glass over like deer in the 
> headlights)....
> 7) Don't expect any organization to give you their security policy. 
> Their first and best answer will usually be 'no'. This is where your 
> application design and specific requirements listed out will be 
> helpful - they should be able to identify those items that work within 
> their security and those that do not.
>
> One thing that should be considered are those organizations that are, 
> have or will be utilizing virtualization such as terminal services, 
> VMware or Citrix. These environments will be controlling the users' 
> systems from services and resources on core servers or clusters. In 
> these cases, even more restrictions may exist than normally exists on 
> standard desktop environments. Virtual environments are at increased 
> risk for implementation of apps/tools on a system that could crash the 
> host and impact many users or resources.
>
> Speaking of desktops...the difference between desktop OS can vary. XP, 
> Vista and now Windows 7 have different levels of access control and 
> permissions. The enterprise is going to control these systems through 
> their SMS or SUS services and global policies may restrict some of the 
> things the application wants to do.  Also be aware that more 
> restrictive environments, such as the federal organizations, may be 
> utilizing IDS/IPS (intrusion detection/prevention) clients that report 
> to centralized management systems. Automated deployment of a tool in 
> these high security environments could trigger risk alarms and create 
> some confusion.
>
> I think the best thing is to be very specific about what types of 
> files are written or read, the level of access each needs, the port 
> calls/requests (ephemeral ports included), etc. The basics of the 
> software design including those elements listed previously would be 
> beneficial for those organizations that will require a security review 
> and/or change control management decisions.
>
> The Nessus scanner is the one I used in the federal government and was 
> the basis for directing an enterprise security management platform 
> around which we developed an open source based tool for managing risk 
> identification, mitigation and audit. It runs great on a Linux 
> platform and has a ton of flexibility. The default settings will 
> generate passive scans, though you can turn up the heat and do full on 
> pen testing with it. The results it spits out are clear and easily 
> understood. Most all come with a link that specifies the patch/fix 
> required to clear the mitigation. Its vulnerability database is 
> populated by the large white hat community. Rarely does it give false 
> positives and they are generally corrected within a months time by 
> Tenable.  Its been a couple years since I built a Nessus scanner but 
> the steps are pretty clear and easy for most anyone to do who can run 
> any of the popular Linux distros.
>
> http://www.nessus.org/nessus/
>
> For those possible clients in the federal community, be prepared to 
> wait for approvals...they typically have a hurry up and wait attitude.

-- 
Phil Davis

PDS Labs
Professional Software Development
http://pdslabs.net