You may be thinking, what's the big deal? After all, anyone can view the source of an HTML page and find all sorts of goodies that we'd prefer the bad guys not see. Hidden fields are hidden only in the sense that they are not displayed within the browser; they still exist in the page and can be read easily. The submission point for a form must be present in the page and can be extracted from the source without much effort. Cookies are stored as plain text and can be viewed as easily as the source of a Web page.
The big deal is that, in most cases, you won't be able to get at information regarding other functions via a conventional Web-based application because the application ensures that you see only what you're authorized to access. Web services, on the other hand, are regular floozies, serving up every function available--regardless of whether the person on the other end is authorized for access.
Bottom line: Most Web-based applications restrict access proactively, while Web services are reactive. And herein lies the problem. To secure Web services during development, you must fix it so that each and every function performs due diligence to ensure that only authorized access is allowed. Although it's practical and desirable to require your developers to validate user input, validating authorization for every function is not only impractical, but it will degrade performance to the point of making the service unusable.
To provide effective security for Web services, we need to move to a proactive model of authentication and authorization. It's much easier, and safer, to require an invitation at the door than to throw crashers out of the party once they've gotten inside. A proactive model provides a centralized security architecture that is not only easier to manage but also enforces policies consistently across the enterprise.
WS-Security and SAML (Security Assertion Markup Language) provide a mechanism for establishing trust between a consumer (client) and a producer (the Web service). Both specifications are flexible and offer myriad options for verifying the credentials of the consumer--user name-password pairs, X.509, e-mail addresses and tokens, as well as digital signatures for identity verification and authorization. Because Web services are open by nature, it is imperative that you require client credentials to be verified and trusted by the Web service. "Integrity is far more important than confidentiality," says Dr. Phillip Hallam-Baker, editor of SAML and co-author of the WS-Security spec. "It's not just the security; it's the trust." Amen.
Some products are capable of deriving user credentials from elements within the XML document. But your method of credential verification is not nearly as important as ensuring that this process is part and parcel of your Web services security strategy. WS-Security is widely supported, as is SAML. In fact, SAML is designated within the WS-Security specification as one method of passing credentials from the consumer to the producer. Because SAML support is offered by a large contingent of identity-management system providers, including Computer Associates, Netegrity, Novell and Oblix, it can be integrated into your infrastructure easily and lets you take advantage of existing infrastructure investments.
To realize the benefits of cloud-native software, an application must actually be cloud-native—designed to run in the cloud, interacting with disaggregated cloud services, fully manageable as code—to deliver the expected benefits.
By combining resources and expertise, the AI-Enabled ICT Workforce Consortium will offer a blueprint for how industries can adapt to an AI-dominated future.
IT leaders should heed the guidance of cybersecurity insurance providers who think businesses should prioritize security education, incident preparedness, regular internal audits, and ongoing vulnerability scanning and patching.
