From: Jörg Maaß (joerg.maass@gmx.de)
Date: Thu Jun 16 2005 - 12:04:17 EDT
Dear Dave,
I read your post with interest, not only because I live in a different
country with different legislation, but also because the problems you
mention are somewhat typical for large organizations, be they governmental
or business.
I do not know the exact content of the regulations you refer to, but the
basic point here is that both vulnerability scans and penetration testing
serve the only purpose of helping to ensure that the computer systems of
said agency comply with or exceed the regulations and are secure.
If the definition of penetration testing adopted by the agency fulfils those
goals, complies with the regulations and is sufficient to help achieve
regulation compliance for the computer systems, fine.
If they do not (and I assume that they do not), then you have a point and it
was absolutely correct to address this fact through the chain of command.
This is totally beside the point of professional conduct, however. In fact,
from a professional point of view, you are correct in assuming that only
running vendor products and call that a penetration test is not sufficient.
Your chain of command's reaction is very typical for a large organization.
"Hey, it's not so important. I have my budget discussion coming up, and Mr.
X from the affected department will kick my ass in those discussions if I
point the finger at him." Typical management reaction.
Perhaps the best course of action is to point out the legal consequences to
you and your boss, as well as the agency, to your chain of command and tell
them that in your opinion, the definition is not sufficient and might
conflict with legal requirements (if that is the case). If they turn you
down, ask for a written confirmation. If they refuse that, you have three
choices:
- Swallow it and continue to work there: Not a good idea, since this
obviously conflicts with your work ethic (which I regard as very high, BTW
:-).
- Address the issue higher up in the chain of command or at a complaints
commission, if there is any, informing your immediate supervisor of your
course of action beforehand: Potentially dangerous for your career and only
feasible if you have your flanks solidly covered.
- Leave the agency: This is the boldest and most ethical step. Make sure
that the recommendation you get is not affected.
Ultimately, the decision is up to you. Since I don't know the environment, I
can't give recommendations (and since it's a personal decision anyway, it
would not be wise to give recommendations, even if I could).
I don't think you are overreacting or exaggerating. Your conduct has been
professional throughout, but keep in mind that security is always a means
towards a goal, and that goal is the fulfilment of business objectives.
If there are regulations in place to ensure that, as is the case in the
agency and other violate those regulations, then this should not be accepted
by the organization and management. However, ultimately it boils down to a
management decision (sometimes at the highest rank in an organization). If
that management has no backbone or is not doing its job properly, then it is
time to move on.
Kind regards
Jörg Maaß
-----Ursprüngliche Nachricht-----
Von: Dave [mailto:dave.anon@gmail.com]
Gesendet: Mittwoch, 15. Juni 2005 16:51
An: pen-test@securityfocus.com
Betreff: Government Compliance
Hello everyone. I know some will view this as a rant and other as
informative, but I am making this post as a sanity check.
For the purposes here, I currently work as an IT Security professional
for the US government. I work at the Department of Government, within
a component named AgencyX. Yes, these names are fictional.
To give an outline or basic background, all government computer
systems are governed by strict requirements for designing,
implementing, maintaining, and securing them. Many of these are
mandatory and are not up for negotiation. Some examples include NIST
SP's, FISMA, DCID 6/3, etc.....
OK....so I received and email from a "IT Security professional"
(qualifications and knowledge very questionable) at the Department in
response to a question I had. I had asked for the definition the
Department was adopting for penetration testing. The response I
received was (scrubbed for anonymity):
"... The guidance for penetration testing was reviewed at [department
committee] meeting... penetration testing shall consist of [product
name deleted] vulnerability scans and running [product name deleted]
for cracking passwords... if this has been done AgencyX shall get
credit for penetration testing...."
Ok, I have big problems with this. There are seperate and distinct
requirements for maintaining password complexity, performing vuln
scans, AND performing penetration testing. Any industry guideline or
resource would never allow this "definition". Am I wrong? Am I over
reacting?
When I brought this up to my chain of command I was told "don't rock
the boat". They fully admitted that they knew the definition to be
incorrect in that it was not meeting the intent of the requirement,
but that I should not say anything to rock the boat and just accept
this.
Obviously, for ethical reasons, I am leaving the agency and the department.
Feedback? Thoughts?
-- Dave
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:54:25 EDT