finding revlet limits in a controlled environment
revdev at pdslabs.net
Tue Dec 8 11:28:57 EST 2009
I'm answering my own question - see below. Maybe it will answer
questions that come up in your world.
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
> 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
> 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.
> For those possible clients in the federal community, be prepared to
> wait for approvals...they typically have a hurry up and wait attitude.
Professional Software Development
More information about the Use-livecode