> Are we in agreement that patching, and vulnerability assessment should
> be a part of the whole machine - but not the machine itself?
>
> -metajunkie
>
>
Hi,
First, thanks for the complements! Next, I think what you're saying is
interesting. I'd like to know how you think that the current practice
of seeking vulnerabilities, waiting on patches, or upgrades, testing
those patches and upgrades to make sure they don't break anything
else, and then starting the cycle over again whenever new
vulnerabilities are found to stay a step ahead (or not too many steps
behind in most cases) isn't a cat and mouse game?
What if for every vulnerability you detected, you considered that
there may be many more similar vulnerabilities in that software, and
so instead of patching that one instance, you looked for an
operational control that would address the whole problem? For example,
your PHP web portal allows an SQL injection through special
characters. The developer releases a patch for it. You can either
apply the patch and run all the functionality/quality tests to make
sure it doesn't break all your 3rd party add-ons (assuming it's not
your personal web page and you care if it breaks) until the next time
or you can start applying some better ingress/egress filtering which
would prevent this problem in all the other interactions via the app
to SQL.
Vulnerabilities are just a way to show us what we haven't controlled
yet. 0-days are just a way to show us we are unprepared for the
unknown. You can react by waiting for a patch or you can find a better
way to control that part of your operations.
If you work to control your operations to make the exploitation of
vulnerabilities ineffective, then you can always patch and test again
if you want. But at least you're starting to break the cycle.
I can see how for some use cases, patching for security is okay and I
have said so:
But for companies, businesses, governments, and any tech who's
supporting home users, the goal should be to get a stable level of
security that's usable and not a race against the unknown.
Sincerely,
-pete.
--
Pete Herzog - Managing Director - pete (at) isecom (dot) org [email concealed]
ISECOM - Institute for Security and Open Methodologies
www.isecom.org - www.osstmm.org
www.hackerhighschool.org - www.badpeopleproject.org
This list is sponsored by: Information Assurance Certification Review Board
Prove to peers and potential employers without a doubt that you can actually do a proper penetration test. IACRB CPT and CEPT certs require a full practical examination in order to become certified.
> be a part of the whole machine - but not the machine itself?
>
> -metajunkie
>
>
Hi,
First, thanks for the complements! Next, I think what you're saying is
interesting. I'd like to know how you think that the current practice
of seeking vulnerabilities, waiting on patches, or upgrades, testing
those patches and upgrades to make sure they don't break anything
else, and then starting the cycle over again whenever new
vulnerabilities are found to stay a step ahead (or not too many steps
behind in most cases) isn't a cat and mouse game?
What if for every vulnerability you detected, you considered that
there may be many more similar vulnerabilities in that software, and
so instead of patching that one instance, you looked for an
operational control that would address the whole problem? For example,
your PHP web portal allows an SQL injection through special
characters. The developer releases a patch for it. You can either
apply the patch and run all the functionality/quality tests to make
sure it doesn't break all your 3rd party add-ons (assuming it's not
your personal web page and you care if it breaks) until the next time
or you can start applying some better ingress/egress filtering which
would prevent this problem in all the other interactions via the app
to SQL.
Vulnerabilities are just a way to show us what we haven't controlled
yet. 0-days are just a way to show us we are unprepared for the
unknown. You can react by waiting for a patch or you can find a better
way to control that part of your operations.
If you work to control your operations to make the exploitation of
vulnerabilities ineffective, then you can always patch and test again
if you want. But at least you're starting to break the cycle.
I can see how for some use cases, patching for security is okay and I
have said so:
https://www.infosecisland.com/blogview/10813-Getting-Off-the-Patch.html
But for companies, businesses, governments, and any tech who's
supporting home users, the goal should be to get a stable level of
security that's usable and not a race against the unknown.
Sincerely,
-pete.
--
Pete Herzog - Managing Director - pete (at) isecom (dot) org [email concealed]
ISECOM - Institute for Security and Open Methodologies
www.isecom.org - www.osstmm.org
www.hackerhighschool.org - www.badpeopleproject.org
------------------------------------------------------------------------
This list is sponsored by: Information Assurance Certification Review Board
Prove to peers and potential employers without a doubt that you can actually do a proper penetration test. IACRB CPT and CEPT certs require a full practical examination in order to become certified.
http://www.iacertification.org
------------------------------------------------------------------------
[ reply ]