#SOA -- where is #security today?

1.29: web.cs/soa/where is security today?:
. I was looking for updates on
how SOA is preventing malware;
instead, I find this claim about SOA's vulnerabilities:

"( Modern buffer overflows are more difficult to exploit
than Aleph One's
smashing the stack for fun and profit.
You should look into modern bypasses to ASLR
such as heap spraying or heap feng shui.
Attacks like jmp2reg (jmp2esp jump2ebx ect...)
are also interesting for bypasses for ASLR.
Attacking ActiveX components is fun.
I used H.D. Moore's AxMan with great success.
Here is the remote code execution exploit I found
using AxMan .
. Here are more exploits that I have written .
. The best fuzzer is by far PeachFuzz,
and writing some pit files for it
can be very fruitful research.
Buffer overflows and sql injection
are the most talked about,
but there are a couple hundred categories for vulnerabilities
and they are identified by CWE numbers.
Its worth exploring, I think it will surprise you
what NIST thinks a vulnerability is.

. that had nothing to do with SOA;
it should have been subtitled
"exploits you can avoid by using SOA" .
what's replacing SOA?:

"( the best practice for SOA
is write good services where you need them.
Over use of SOA will increase your latency. ...);

but, the root of all evil
on the internet and on the desktop,
is balancing security with efficiency .
. a primary objective of SOA is security,
so, that is what we're balancing latency with .
1.31:
. SOA means converting all subprogram calls
into messages that get logged,
and then these are resolved into calls .
. there is no need for a firewall at the site;
instead, every subprogram is an authenticated user,
and there's a firewall between each subprogram .
. when malware infects one component,
it's not infecting the entire site unnoticed .
. an auditing thread is checking the logs,
and unusual behaviors can result in rollbacks .

SOA explained in plain english:

"( Can someone explain in plain english
what is SOA all about?
Is there an idiot's guide on this? )

-- idiot's guide?
yes, that's where I learned it!
the 2006 version of the For Dummies book;
the 2nd version seems less appreciated .
1.29: 1.31:
. the point of SOA is that every service is a user,
and every user leaves an auditable trail;
so, instead of security at the city's perimeter,
police are constantly checking the ID of everyone,
every time they cross the street!
. when we invite a new app into our community
we are getting a new user of os services;
the app is no longer assumed to have
the same credentials as the installing user;
and no users are assumed to have
the same trustworthiness they had yesterday .

the best answer was said to be this:
what soa is:

"(  SOA is a style of architecting
composed of discrete software agents
that have simple, well defined interfaces
and are orchestrated through a loose coupling .
There are 2 roles in SOA
- a service provider and a service consumer.
    A software agent may play both roles.)

-- yes but,
the point of SOA is security,
which that article's author doesn't even mention;
SOA provides high security
by avoiding perimeter-only security .

. here's what SOA has to do with web services:
an SOA implemented via a web service
would be implemented by giving every OS service
its own net address,
and then for every website of your OS
you would require every app
to be a registered web user
(to have a public record to write reports in,
and be registered uniquely, by unique bot token
like a human fingerprint card);
and every service would log who its callers were;
so, no user can exploit the system
without potentially giving away how the exploit is done;
logs have to be cleared at some point
so investigations have to be on-going ...

1.29: 1.31:
. on the practical level for business,
it was also about walmart-style automation:
replace all those human silo operators
with automated service managers .
(walmart had problems with human jobbers,
the guys that coordinate distribution
from wholesale to retail;
they couldn't make much money serving a small guy
so sometimes they just didn't provide product .
. that's when Walmart got into the jobber business,
and automated it ... revenge of the Nerds! )
1.31:
. the IT analog of that is the data silo,
where a needed database is stored within an app,
and to do anything with that data,
you had to shuffle papers to the app's operator .
. SOA can cut out that app operator
by making the app respond to something like emails,
and have various apps emailing each other .
SOA, the silo killer:

. most SOA or enterprise service efforts
are "islands" of integration
that arise within individual business units,
designed to address specific problems.
The challenge is that these separate SOA efforts
have different formats and technologies .
Many use app servers, some use middleware,
and others rely on a department-local ESB
(enterprise service bus).
First, on a technology level,
move to a federated infrastructure
to support multiple instances of ESBs or intermediaries.
. rather than trying to manage a growing SOA
through a single ESB,
federated infrastructures are more likely to
be able to move from siloed SOA
to enterprise-scale SOA.
. on a business level,
automating your governance will make the difference
between ending up with a tangle of services
-- JBOWS(Just a Bunch of Web Services)  --
or a functioning SOA that truly supports
end-to-end business endeavors across the enterprise.

JBOWS: Web services do not equal SOA:

. having JBOWS (Just a Bunch of Web Services)
is Brittle, and non-scalable,
because it doesn't help with forwarding
when a provider is no longer available .
. an SOA provides Economies of scale,
and has built-in fault tolerance:
the customer asks for a service,
and the system finds an available provider .
. if the customer requests a provider,
and that provider is not available,
the system finds an equivalent provider

-- automated governance .