Home page logo
/

basics logo Security Basics mailing list archives

RE: Binary Analysis with Internal Solutions
From: "Simon Thornton" <simon () thornton info>
Date: Wed, 25 Jul 2012 11:00:35 +0200

Mikhail,

It doesn't need to be a book, only an enumeration of your thought processes
as to why it is necessary. Many of the risk assessment methodologies are too
heavy and complex for common use unless they are embedded into an
organisation from the top down. Most risk assessments are subjective since
they look at only small parts of a much larger eco system. Consistency in
approach is very helpful in justifying to management why they need to allow
us to do something and what investments maybe needed to reduce the risk. 

I agree with you that you cannot determine the number of attacks but you can
try and determine what the potential exposure to attacks is in your
environment. For example, an internet connected web portal has a far larger
number of potential attackers than say a PABX terminal sitting on a
dedicated firewalled DMZ off the internal LAN. Sure you can get malware
infections on internal machines that are then used to jump onto the internal
application but that is a separate issue. Another relates to the data
involved; if a web portal provides access to "public" data and breach should
have negligible impact beyond business image. However if the same portal
were to contain confidential credit card data or highly confidential patient
records then a breach would have consequences (financial and legal) on the
business. 

No one can hold you responsible if you have tried to quantify the risk and
based your assessments and controls on this.

MU> "However, I bet you are talking practical matters, so do not
MU> do any risk assessment IF - see above about job security."

This isn't about job security but consistency in approach; if we want as
security professionals to have more impact on how businesses work then we
need to work in ways that the business can relate (bearing in mind that IT
is not the business but a support to it for most companies.

Rgds,

Simon

-----Original Message-----
From: Mikhail A. Utin [mailto:mutin () commonwealthcare org] 
Sent: Tuesday, July 24, 2012 21:30 PM
To: Simon Thornton; security-basics () securityfocus com; nschroedl () mtiorg com
Subject: RE: Binary Analysis with Internal Solutions

Nick,
And Simon as recommending so named "risk analysis".
If you want to be dragged in discovering of the Universe of InfoSec
exploits/attacks/malware/etc., you can try Simon's " Part of the answer
depends on the perceived attack surface (the risk of an attack) and the
impact a successful compromise would have."
I wrote twice to this list that the number of attacks is unknown, and
concerning the exposure of each in your company (infinite number - you can
do that estimate for your job security for the rest of your life. BTW, both
components are changing daily.

Quantitative risk analysis is good if you need to write a document for
compliance matters, and nobody will be able to object your estimate as right
estimates are unknown.
So, use your common sense, which is qualitative risk analysis.

However, I bet you are talking practical matters, so do not do any risk
assessment IF - see above about job security.

Mikhail Utin,  CISSP, PhD


-----Original Message-----
From: listbounce () securityfocus com [mailto:listbounce () securityfocus com] On
Behalf Of Simon Thornton
Sent: Tuesday, July 24, 2012 12:35 PM
To: security-basics () securityfocus com; nschroedl () mtiorg com
Subject: RE: Binary Analysis with Internal Solutions

Hi Nick, 

NS> "Should binary analysis (i.e. reversing and fuzzing) be part of an 
NS> internal vulnerability and pen testing solution?"

You are asking about two different activities with widely different
requirements in terms of the time and potentially resources needed. Fuzzing
is the simpler of the two exercises and can be automated, often used as part
of pentesting exercises. Reverse engineering is largely a manual process and
can be significantly more challenging and time consuming.

Part of the answer depends on the perceived attack surface (the risk of an
attack) and the impact a successful compromise would have. If this is an
internal application on a closed network not connected to the internet then
it may be worth it. If however this application contains data covered by
regulatory compliance and/or legal requirements (privacy laws) and it is
exposed directly or indirectly to the internet then this is different.

Start with a simple risk assessment, considering the data (classification)
processed by the application, location of the service, who accesses it etc.
This should give you an indication if you need to consider more in-depth
analysis. To go as far as reverse engineering would normally be predicated
by an event which cannot be explained by looking at source code, logs etc.
Examples might be

- if a security incident or breach occurred which could not be explained by
other analysis. 
- Another example might be a requirement (legal/regulatory) that all
applications used strong ciphers or long key lengths and the source code was
not available.

My experience; most of the time reverse engineering is not justified from a
cost/risk perspective. Fuzzing interfaces can detect functional bugs not
caught through normal testing.  Whatever the source of a vulnerability or
issue the risk (impact/exploitability or impact/likelihood) needs to be
addressed.


Simon 


-----Original Message-----
From: listbounce () securityfocus com [mailto:listbounce () securityfocus com] On
Behalf Of nschroedl () mtiorg com
Sent: Tuesday, July 24, 2012 17:15 PM
To: security-basics () securityfocus com
Subject: Binary Analysis with Internal Solutions 

Hello everyone, 

                A debate has been started in the office that I work in over
this question.  

"Should binary analysis (i.e. reversing and fuzzing) be part of an internal
vulnerability and pen testing solution?" 

                There is mission critical custom in house software solutions
deployed here.  My opinion is Yes, but others say it is a waste of resources
to go this deep into offensive security.  Please send your comments, and
opinions so that I can either win/loose this debate.

Nick Schroedl 



------------------------------------------------------------------------

CONFIDENTIALITY NOTICE: This email communication and any attachments may
contain confidential 
and privileged information for the use of the designated recipients named
above. If you are 
not the intended recipient, you are hereby notified that you have received
this communication 
in error and that any review, disclosure, dissemination, distribution or
copying of it or its 
contents is prohibited. If you have received this communication in error,
please reply to the 
sender immediately or by telephone at (617) 426-0600 and destroy all copies
of this communication 
and any attachments. For further information regarding Commonwealth Care
Alliance's privacy policy, 
please visit our Internet web site at http://www.commonwealthcare.org.


Attachment: smime.p7s
Description:


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]