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
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
