Using the Ethical Hacking Process

Using the Ethical Hacking Process

Like    practically    any    IT    or    security    project,    you    need    to    plan    your    security    testing.    It’s been    said    that action    without    planning    is    at    the    root    of    every    failure.    Strategic    and tactical    issues    in    the    ethical hacking    process    need    to    be    determined    and    agreed    upon.    To ensure    the    success    of    your    efforts,    spend time    up    front    planning    for    any    amount    of testing    —    from    a    simple    OS    password-cracking    test    against a    few    servers    to    an    all-out vulnerability    assessment    of    a    web    environment.

Formulating    your    plan
Getting    approval    for    security    testing    is    essential.    Make    sure    that    what    you’re    doing    is known    and  visible    —    at    least    to    the    decision    makers.    Obtaining    sponsorship    of    the project    is    the    first    step.    This is    how    your    testing    objectives    will    be    defined.    Sponsorship could    come    from    your    manager,    an  executive,    your    client,    or    even    yourself    if    you’re    the boss.    You    need    someone    to    back    you    up    and  sign    off    on    your    plan.    Otherwise,    your testing    might    be    called    off    unexpectedly    if    someone    (including third    parties    such    as cloud    service    and    hosting    providers)    claims    you    were    never    authorized    to    perform the tests.    Even    worse,    you    get    fired    or    charged    with    criminal    activity    —    it    has    happened!

The authorization    can    be    as    simple    as    an    internal    memo    or    an    e-mail    from    your    boss when    you perform    these    tests    on    your    own    systems.    If    you’re    testing    for    a    client,    have    a signed    contract    stating the    client’s    support    and    authorization.    Get    written    approval    on this    sponsorship    as    soon    as    possible    to ensure    that    none    of    your    time    or    effort    is    wasted. This    documentation    is    your    “Get    Out    of    Jail   Free”    card    if    anyone    such    as    your    Internet Service    Provider    (ISP),    cloud    service    provider,    or    related vendor    questions    what    you’re doing,    or    worse,    if    the    authorities    come    calling.    Don’t    laugh    —    it wouldn’t    be    the    first time    it    has    happened.

One    slip    can    crash    your    systems    —    not    necessarily    what    anyone    wants.    You    need    a detailed    plan,  but    that    doesn’t    mean    you    need    volumes    of    testing    procedures    to    make things    overly    complex.    A    well-defined    scope    includes    the    following    information:

Specific    systems    to    be    tested:    When    selecting    systems    to    test,    start    with    the    most critical    systems    and    processes    or    the    ones    you    suspect    are    the    most    vulnerable.    For instance,    you    can    test    server    OS    passwords,    test    an    Internet-facing    web    application, or    attempt    social    engineering    via    e-mail    phishing    before    drilling    down    into    all    your systems.

Risks    involved:    Have    a    contingency    plan    for    your    ethical    hacking    process    in    case something    goes    awry.    What    if    you’re    assessing    your    firewall    or    web    application and    you    take    it    down?    This    can    cause    system    unavailability,    which    can    reduce system    performance    or    employee    productivity.    Even    worse,    it    might    cause    loss    of data    integrity,    loss    of    data    itself,    and    even    bad    publicity.    It’ll    most    certainly    tick    off a    person    or    two    and    make    you    look    bad.
Handle    social    engineering    and    DoS    attacks    carefully.    Determine    how    they    affect    the people    and    systems    you    test.

Dates    the    tests    will    be    performed    and    your    overall    timeline:    Determining    when the    tests    are    performed    is    something    you    must    think    long    and    hard    about.    Do    you perform    tests    during    normal    business    hours?    How    about    late    at    night    or    early    in    the morning    so    that    production    systems    aren’t    affected?    Involve    others    to    make    sure they    approve    of    your    timing.

You    may    get    pushback    and    suffer    DoS-related    consequences,    but    the    best    approach is    an    unlimited    attack,    where    any    type    of    test    is    possible    at    any    time    of    day.    The    bad guys    aren’t    breaking    into    your    systems    within    a    limited    scope,    so    why    should    you? Some    exceptions    to    this    approach    are    performing    all    out    DoS    attacks,    social engineering,    and    physical    security    tests.

Whether    or    not    you    intend    to    be    detected:    One    of    your    goals    might    be    to perform    the    tests    without    being    detected.    For    example,    you    might    perform    your tests    on    remote    systems    or    on    a    remote    office    and    you    might    not    want    the    users    to be    aware    of    what    you’re    doing.    Otherwise,    the    users    or    IT    staff    might    catch    on    to you    and    be    on    their    best    behavior    —    instead    of    their    normal    behavior.

Knowledge    of    the    systems    you    have    before    you    start    testing:    You    don’t    need extensive    knowledge    of    the    systems    you’re    testing    —    just    a    basic    understanding. This    basic    understanding    helps    protect    you    and    the    tested    systems. Understanding    the    systems    you’re    testing    shouldn’t    be    difficult    if    you’re    hacking your    own    in-house    systems.    If    you’re    testing    a    client’s    systems,    you    may    have    to dig    deeper.    In    fact,    I’ve    only    had    one    or    two    clients    ask    for    a    fully    blind    assessment. Most    IT    managers    and    others    responsible    for    security    are    scared    of    these assessments    —    and    they    can    take    more    time,    cost    more,    and    be    less    effective.    Base the    type    of    test    you    perform    on    your    organization’s    or    client’s    needs.

Actions    you    will    take    when    a    major    vulnerability    is    discovered:    Don’t    stop    after you    find    one    or    two    security    holes.    Keep    going    to    see    what    else    you    can    discover. I’m    not    saying    to    keep    hacking    until    the    end    of    time    or    until    you    crash    all    your systems;    ain’t    nobody    got    time    for    that!    Instead,    simply    pursue    the    path    you’re going    down    until    you    just    can’t    hack    it    any    longer    (pun    intended).    If    you    haven’t found    any    vulnerabilities,    you    haven’t    looked    hard    enough.    They’re    there.    If    you uncover    something    big,    you    need    to    share    that    information    with    the    key    players (developers,    DBAs,    IT    managers,    and    so    on)    as    soon    as    possible    to    plug    the    hole before    it’s    exploited.

The    specific    deliverables:    This    includes    vulnerability    scanner    reports    and    your own    distilled    report    outlining    the    important    vulnerabilities    to    address,    along    with recommendations    and    countermeasures    to    implement.


For any query or issue, feel free to discuss on http://discuss.eduguru.in