Re: What I don't understand...
Agree, as an ex-bank InfoSec bod, this has insider job all over it. Even if the bank is running a COTS platform, a fair bit of insider knowledge would be required to pull off what has been described.
31 publicly visible posts • joined 18 Jun 2013
These are mostly skills issues.
Lots of companies are upgrading/migrating from ERP versions to S/4, which is a reasonably chunky piece of work.
Initial take-up of S/4 was slow, hence there aren't that many people who really know how to do an upgrade, especially in a complex environment. Those with the skills are in great demand now but there aren't enough to meet demand.
This isn't exactly a new phenomenon but one thing we know and love about the SAP industry is that "experienced" project managers, implementers, consultants, love to make the same mistakes over and over again.
There are a few thing at play here.
For a while, Indian govt has wanted to control and have access to payment data, similar to what China has implemented. RuPay was a start but has limited adoption.
Earlier outages at HDFC & SBI enabled the RBI (regulators) to ratchet up oversight, with some of their requirements & practices being ridiculous & nonsensical.
Data localisation was the start, under the guise of privacy it’s putting data where Indian govt can exert more control. RBI decided to flex their muscles by preventing some FIs from acquiring new customers despite agreeing to proposed timelines.
Now they are going for development & operations. This is not about risks & resilience, it’s about access to their citizens data and a degree of control over their finances.
Tax evasion is a big problem in India, but this is the thin end of the wedge.
A few years back my missus used to run a program at a consultancy firm, the objective was to do well in these surveys.
A lot of effort went into ensuring that only the right types of people were selected to complete the surveys, a population of about 100. Those individuals weren’t coached, coerced, or otherwise encouraged to answer in a particular way, however they were pretty safe bets.
In a number of respects the SAP cloud products are more attractive than on prem (in particular around encryption & security in general).
It's a difficult one for SAP but one of their own making. Lots of their clients are happy with business suite & the usual add-ons. Tens of millions of people know how to use it (they may not like it but they do know it). Large customers are fully invested and have ecosystems supporting SAP. Cloudify it too much and lots of that value is lost. SAP are desperate to get hosting/support/config revenue off the SI's and into their pockets. From what I have seen customers are keen to migrate their workloads onto cloud but don't want the "reimagined innovation platform" type bollocks that SAP are peddling.
ESNC & PwC aren't in competition. PwC's ACE is an audit support tool. It extracts the information used to audit SAP systems, generally for the purposes of supporting statutory audit. Primarily ACE performs Segregation of Duties reviews. The ESNC products are more focused towards technical security - VAs etc.
In the U.K. Deloitte hoovered up the AA audit teams but it varied for other countries.
Putting this into context, this is crappy coding but not uncommon among vendor or SAP code. I would also be surprised if this was remotely executable for any organisations following the standard security guidance provided by SAP.
I'm not that surprised that something like this has been picked up, there are lots of vendor tools using exactly the same lazy techniques to auto generate code. PwC are unlucky as they are an easy target & their response was pretty crappy. They really should have been whiter than white. There will be plenty of vendors scrambling to check their code now. I would have imagined a fair few of them would have been scanned by VirtualForge who pretty much own the SAP code scanning space. They don't really need to publicise though. You have to also question SAP for remaining to make those techniques available, doing that would likely require a lot of refactoring (and vendors are "encouraged" to not scan SAP code outside of direct collaboration with them)
For those commenting on the tool, ACE is the name of many junior SAP auditors lives. It uses client side ABAP programs to generate extract files which are taken processed separately to identify stuff like segregation of duties conflicts, change control settings, configurable control settings etc. From what I remember it can't be used to make updates though it sounds like the programs could be subverted.
I'm not disputing that there are 256-odd systems discoverable with that service.
It has been a slow news month for SAP with regard to reporting security bugs and for the article (not the vendor) to say it is critical is simply not the case. It relates to information disclosure which at worst, could be used to support an attack to be crafted.
A fair bit of hyperbole here. The authentication bug was for an information service & the info that can be gained isn't particularly useful, certainly not a critical prior and not classified by SAP as such.
With regard to giving code to customers - in general it is (with a few exceptions). While it's not open source, it is available to anyone with an SAP system - a lot of customers & partners.
Historically I don't think SAP would have been too bothered, after all where their customers data is is not their problem.
Now SAP are going all out on a cloud strategy where SAP hosts, all of a sudden it can bite them on the bum rather than just their customers.
There is a common misconception with the SAP industrye that traffic is encrypted rather than compressed & obfuscated. SAP recommend that encryption is enabled but <10% of customers actually do it (either using SAP tech or other solutions). It seems that the term has been used to drum up a bit more excitement.
SAP have really upped their game in the security area over the last 5 years. While many, many customers subscribe to security by obscurity, the same doesn't apply to SAP.
The problem is that many customers will not invest in securing their assets using standard mechanisms that SAP have provided for years, party because it is, just like you say, an utter faff to patch around release cycles.
I've got plenty of clients who have done the same. Set up an entity in a low(sh)-tax location e.g. Switzerland.
Step 1. Transport some staff to Head Office & claim that's where decisions are made, sales happen & risk is taken (therefore where tax should be paid)
Step 2. Set up new companies overseas & transfer manufacturing, service, distribution and local procurement into those companies.
Step 3. Operate tolling system where H/O owns stock & pays local manufacturers to covert raw materials into product & ship on behalf of Head Office.
A few honchos move, lots of people get new contracts in the new companies.
We've been able to find SAP systems through internet searches since the days of ITS and early SAP Portal. It would have been a trivial matter to try some default user accounts.
Other posters have commented on the reality of the tests & possible scaremongering tactics. For all their sins SAP does generally produce reasonably secure software. The problem is that most of those paid to secure it do not understand how to secure the assets using standard delivered SAP functionality and standard security techniques.
Unfortunately this is no surprise to many of us working in the SAP security field. SAP are working very hard to improve, unfortunately clients are struggling to care.
Some key themes:
1. Security admins main knowledge is around building roles/permission structures and user admin. The technical side is neglected (despite being covered quite well in certification) and there is a big gap.
2. Patching is time consuming and many organisations require full regression testing for each set of patches. Across 20 productive systems (each with a supporting application stack of 2-5 systems) covering a full scope of business processes that comes at quite a cost (though not as much as a breach of course).
3. IS teams rarely talk to SAP teams. SAP has been treated as a silo & there is a disconnect between IS and their SAP counterparts. Many SAP admins do not understand the impact of vulnerabilities, the IS teams struggle to use terms that the SAP guys understand.
Fortunately some people do "get it" and plenty of orgs are doing good stuff & SAP is committed to make it easy for people to do the right thing.
Disclaimer: I work for a company doing security for SAP