Information Assuranceinformation assurance degree onlineInformation Assurance Jobsrisk jobs

security engineer

security-engineer

System Security Engineer is a critical job in the cyberspace workforce.  As information technology has become a centerpiece for our lives, the security of IT has been more and more in demand.  A security engineer is expected to have a working understanding of IT enough to be able to strike a balance between operational functionality and application security controls.

System Security Engineer (ISSE, CSSE, SSE I/S Security Engineer) actually can mean anything.. So you actually need to read the job description.  But in this post, I am referring to SSE from the perspective Risk Management and DIARMF.

DIARMF Select balance
DIARMF
blog.eircomforbusiness.com/profile/Andy (andy O’Kelly, eircomforbusiness.com)

And Risk Management SSE needs to be savvy enough with the operational needs and security needs to balance the risk.  While a security engineer does not take risks of the organization they work for, they do consult the decision makers that do take risks.

Many security engineers are not hands on.  Meaning they might not touch the servers or configure routers, but they must know enough to orchestrate the over all security of the organization or system they are assigned to.

System Security Engineering Tasks

I have been in system security engineer positions where I did have hands-on tasks working directly with the system administrators and I have had some where I rarely even seen the systems that I wrote system security plans for.

System Security Engineers do consultation where they are working directly with information owners, project managers, information system security managers or technical security practitioners to come up with the most cost effective strategy for applying security controls with a certain level of effort within a certain time constraint.   A good security engineer understands all these factors and make sure the decision makers are well informed.  As an SSE the last thing you want to do is a prima madonna and attempt to put security beyond the scope of the operational mission.  And don’t be a hero, even if you really care about the mission you must ALWAYS remember the risk is not yours to bear and neither is the decision of what security controls (if any) will be applied.

Tasks of a system security engineer  

System security engineers do system security related documentation such as system security plans, plan of action and milestones, security assessment reports and other supporting documentation.

A day in the life of a system security engineer might consist of attending configuration management meetings, meeting with system administrators to address new challenges, writing authorization packages, coordinating with other units to complete an authorization package, reading the latest change to a regulation or organizational standard, WRITING an organizational standard and in some cases they are actually doing security administration on some system.

CYBER System Security Engineer (CSSE)

With Dod 8140 and the cyber-ization of the every goddamn thing! I believe the new term will be CYBER System Security Engineer (CSSE) and in the past it was commonly refer to as an Information System Security Engineer (ISSE).

As stated above and SSE can be just about anything computer security related.  I have been a SSE and done nothing put paperwork but also been an SSE and done mostly installations of system security controls.  My former co-worker just got a position as an Information System Security Engineer (I/SE) and he will be doing all ArcSight admin stuff.

read more
DIARMF

dod 8140

dod 8140
Dod 8140 DoD 8140, Cyberspace workforce will supersede DoD 8570 as the guide for selecting the personnel with the correct certifications, skills and experience. DoDD
read more
DIARMFrisk management

risk evaluation

risk-evaluation

A risk evaluation from a system security perspective is known as a risk assessment (or security assessment).  The process of the risk evaluation is detailed in NIST SP 800-30, Guide for Risk Assessments and NIST SP 800-39, Risk Management.

Risk evaluation means risk identification.  Risk identification has 7 mains steps  (two additional steps dedicated to recommendation and documentation):

1)  System characterization –  a System Security Plan (SSP).  Evaluate the Asset information covers the following:

  • Hardware
  • Software
  • System interfaces (e.g., internal and external connectivity)
  • Data and information
  • Persons who support and use the IT system
  • System mission (e.g., the processes performed by the IT system)
  • System and data critical (e.g., the system’s value or importance to an organization)
  • System and data sensitivity

2)  Threat Evaluation – Evaluate possible threat sources by looking at what negative activities are likely to happen to the system.

3)  Vulnerability Evaluation – Look at the vulnerabilities and evaluate the biggest weakness in the systems.

4)  Security Control Evaluation – Examine what controls the system already has applied.

risk evaluation
risk evaluation

5)  Likelihood of occurrence evaluation – The probability that your asset will be exploited is based on the threat source motivation, threat capability, your vulnerability and the security controls you have in place.   Based on all these factors you can calculated the likelihood of an attack or disaster.

6)  Impact Evaluation – This where you gather all the data from asset identification, threat source, vulnerability identification, security controls, likelihood of attack and figure you what would happen if something really did happen.  How important is your system and its data?  What would happen to the mission or bottom line or profits if the system went down for a few hours?  a few days? a few weeks?  Some system are so important that they cannot be down for even a minute.  Impact is very important to the level of risk.  The more important the system is, the high the risk.

7)  Risk Determination / Risk Evaluation – Based on all the data gathered you can make a pretty good risk determination.  You should have defined the systems components and what data is important, made a pretty good conclusion on threat sources and likelihood of the vulnerability exploits and know exactly what kind of impact there will be if the system goes down.

 

risk evaluation
risk evaluation
read more
1 52 53 54 55 56 57
Page 54 of 57